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ft  This  paper  is  the  result  of  work  performed  by  the  Institute  for  Defense  Analyses 

(IDA)  under  contract  number  MDA  903  89  C  0003,  Task  Order  T-D6-554,  Amendment 
Number  2,  "Measurement  Issues  in  Unified  Life  Cycle  Engineering."  This  work  was 
performed  for  the  Air  Force  Human  Resources  Laboratory,  Logistics  and  Human  Factors 
ft  Division,  and  the  Under  Secretary  of  Defense  for  Acquisition  (USD(A)).  The  report 

addresses  development  of  a  methodology  tor  assessing  and  ranking  designs  with  respect  to 
one  or  more  aspects  of  supportability  and  specifically  addresses  tasks  4.a,  4.b,  and  4.c  in 
the  task  order. 

*  This  paper  was  reviewed  by  Dr.  Jeffrey  H.  Grotte,  of  IDA,  Dr.  Joel  Tumarkin,  an 

IDA  consultant,  and  Mr.  Frank  Roth,  of  Texas  Instruments. 
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EXECUTIVE  SUMMARY 


A.  OBJECTIVE 

This  paper  presents  the  results  of  a  research  project  that  had  the  objective  of 
demonstrating  how  the  conceptual  approach  of  the  Boothroyd  and  Dewhurst  Design  for 
Assembly  (DFA)  process  could  be  applied  to  developing  products  that  are  more  easily 
supported  in  the  field. 

In  this  project,  a  specific  methodology  was  developed  that  allows  a  product 
development  team  to  make  system-level  trade-offs  between  redundant  part  selection  and 
scheduled  maintenance  visits  in  order  to  achieve  both  low  life  cycle  cost  (LCC)  and  high 
operational  readiness  of  the  resulting  system.  This  methodology  was  demonstrated  for  a 
subsystem  of  a  ground-based  radar  and  evaluated  by  participants  in  the  demonstration. 

B.  BACKGROUND 

The  Department  of  Defense  (DoD)  has  recently  focused  on  correcting  problems 
within  the  weapon  system  acquisition  process.  Concurrent  engineering,  an  approach  to 
product  development,  has  been  advanced  as  a  potential  solution  to  problems  in  weapon 
system  acquisition  related  to  designs  that  are  difficult  to  produce  and  support  in  the  field. 
This  approach  involves  use  of  a  multifunctional  team  with  representatives  from  all  relevant 
parts  of  government  and  industry  (product  users,  designers,  manufacturing  engineers,  and 
logistics  support  specialists)  to  develop-in  parallel-the  product  design  and  the  associated 
processes  for  manufacture  and  support.  Such  an  approach  significantly  reduces 
development  cost  and  lead  time  and  results  in  products  that  are  easier  to  make,  use,  and 
support  and  are  more  reliable  in  operation. 

To  successfully  implement  a  concurrent  engineering  approach,  a  structured 
methodology  for  aiding  the  multifunctional  team  in  developing  the  product  is  needed.  In 
fact,  several  methodologies  are  needed,  depending  on  the  specific  aspects  of  the  product 
being  considered  by  the  team.  Quality  function  deployment,  for  example,  is  a  useful 
structured  group  technique  for  translating  customer  needs  into  design  requirements  and 
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tracking  the  rationale  for  specific  design  decisions.  Another  technique  that  has  proven  very 
useful  in  helping  product  developers  to  improve  designs  from  the  standpoint  of 
manufacturing  is  the  Boothroyd-Dewhurst  DFA  methodology.  The  key  elements  of  this 
methodology  are 

•  Product  development  by  a  multifunctional  team 

•  Relative  assessment  of  alternative  designs  with  a  metric 

•  Training  in  fundamentals  of  the  methodology  and  underlying  metric 

•  A  specific  procedure  for  creating  alternative  designs 

•  Computer  support  during  team  product  development  meetings. 

Ease  of  assembly  is  only  one  aspect  of  a  design  that  affects  its  LCC.  Product 
supportability  also  significandy  affects  LCC  and  should  be  considered  by  a  concurrent 
engineering  team  early  in  the  product  development  process.  In  this  project,  the  research 
team  investigated  how  the  conceptual  approach  of  Boothroyd  and  Dewhurst  could  be 
applied  to  the  area  of  supportability.  The  research  team  sought  to  identify  certain  aspects  of 
supportability  that  are  of  importance  to  DoD  and  for  which  specific  implementations  of  the 
general  elements  of  the  DFA  approach  could  be  developed  and  demonstrated. 

C.  APPROACH 

An  extensive  literature  review  was  initiated  at  the  beginning  of  the  task  to  identify 
existing  techniques  for  defining,  measuring,  and  designing  for  supportability.  The  goal  of 
this  review  was  to  identify  aspects  of  supportability  to  focus  on.  As  a  result,  the  research 
team,  in  cooperation  with  the  sponsor,  decided  to  limit  the  aspects  of  supportability 
considered  in  this  investigation  to  maintainability,  reliability,  and  logistics  support,  in  this 
order  of  priority. 

Since  maintainability  received  the  highest  priority,  the  research  team  refined  the 
literature  review  to  focus  on  maintainability  and  identify  methodologies  and  guidelines  used 
in  design  fen*  maintainability. 

The  literature  review  established  that  no  universally  accepted  definition  of 
maintainability  exists  [Ref.  1].  No  concise,  manageable  set  of  generic  guidelines  for 
design  for  maintainability  could  be  gleaned  from  the  extensive  lists  found  in  various 
government  and  industry  references.  The  research  team  determined  that  design  for 
maintainability  guidelines  must  be  specifically  tailored  to  the  product  being  developed. 
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This  finding  prompted  the  research  team  to  further  restrict  its  attention  to  a  specific  design 
problem. 

Maintainability,  reliability,  and  logistics  support,  are  all  related  and  should  be 
considered  together  in  designing  a  system  for  supportability.  Isolated  consideration  of  one 
aspect  of  supportability,  such  as  maintainability,  is  not  a  desirable  approach.  To  achieve  a 
good  design— in  terms  of  supportability-the  design  team  must  be  able  to  analyze  the  effects 
of  trade-offs  among  these  design  attributes. 

To  more  specifically  identify  the  kinds  of  trade-offs  that  would  be  appropriate  for 
consideration  in  this  project,  the  research  team  collaborated  with  academia  and  industry 
through  a  cooperative  arrangement  with  the  University  of  Maryland  Center  for  Computer- 
Aided  Life  Cycle  Engineering  (CALCE).  This  center,  an  industry-university  cooperative 
research  center  sponsored  by  the  National  Science  Foundation,  has  as  its  primary  focus 
development  of  new  techniques  for  designing  electronic  products  for  reliability, 
maintainability,  and  supportability.  The  CALCE  center  is  the  only  center  of  its  kind  in  the 
country  that  is  focusing  on  design  for  supportability  of  electronics.  Its  director.  Dr. 
Michael  Pecht,  is  a  nationally  recognized  expert  in  design  of  electronic  systems  for 
supportability. 

A  number  of  major  industrial  defense  electronics  suppliers  are  members  of  the 
CALCE  center- Westinghouse  Electric,  Texas  Instruments,  Digital  Equipment  Corporation, 
Northrop,  General  Electric,  Allied  Signal,  and  General  Dynamics.  Westinghouse  Electric 
and  Texas  Instruments  agreed  to  provide  technical  support  to  IDA  in  the  development  of  the 
methodology  and  to  participate  in  a  demonstration  and  evaluation  of  the  methodology  at  the 
conclusion  of  the  project. 

The  ARSR-4  was  selected  as  the  baseline  system  to  be  used  for  development  of  the 
methodology.  The  ARSR-4  is  a  ground-based,  long-range  3-D  radar  currently  under 
development  by  Westinghouse  Electric.  The  system  is  being  designed  to  meet  the  air  traffic 
control  and  air  defense  sensor  requirements  of  the  Federal  Aviation  Administration  (FAA) 
and  the  U.S.  Air  Force’s  Joint  Surveillance  System  (JSS).  The  ARSR-4  was  selected  for 
the  methodology  development  because  the  design  information  (and  designers)  needed  for 
the  methodology  was  readily  available,  and  Westinghouse  Electric  was  willing  to  supply 
this  information  to  the  CALCE  Center.  In  addition,  considerations  of  supportability  are 
playing  a  significant  role  in  the  design  of  the  ARSR-4. 


D .  METHODOLOGY  DEVELOPMENT 

The  ARSR-4  is  being  designed  by  Westinghouse  for  unattended  operation  and  low 
LCC.  The  only  support  equipment  it  will  require  is  a  limited  number  of  tools  on  site  and 
equipment  already  part  of  the  FAA/Air  Force  inventory.  To  achieve  high  reliability  and 
allow  continuous  operation,  redundancy  is  used  extensively  in  the  design  of  this  system. 
Scheduled  maintenance  visits  are  also  used  to  enhance  reliability  through  periodic 
replacement  of  failed  redundant  components. 

These  approaches  to  enhancing  reliability  are  not  without  cost,  however. 
Increasing  the  number  of  redundant  components  increases  system  acquisition  cost,  while 
increasing  the  frequency  of  maintenance  visits  increases  system  logistics  support  cost.  If  a 
given  level  of  system  reliability  is  required,  increasing  redundancy  allows  the  frequency  of 
maintenance  visits  to  be  reduced,  and  conversely,  increasing  the  frequency  of  maintenance 
visits  allows  redundancy  to  be  reduced.  The  net  LCC  impact  of  changing  both  redundancy 
and  maintenance  visit  frequency  will  depend  on  the  relative  magnitudes  of  such  factors  as 
the  cost  of  the  parts  being  made  redundant,  manpower  and  transportation  costs  associated 
with  maintenance  visits,  and  spares  costs. 

To  minimize  the  total  system  LCC,  which  includes  both  acquisition  and  support 
costs,  a  method  for  obtaining  the  proper  balance  between  redundancy  and  maintenance  visit 
frequency  is  needed.  To  obtain  such  a  balance,  the  product  development  team  needs  the 
freedom  to  vary  both  the  level  of  redundancy  and  the  frequency  of  maintenance  visits,  and 
the  capability  to  estimate  the  LCC  impact  of  such  changes. 

In  the  current  government  acquisition  process  for  the  ARSR-4,  the  product 
developer  was  given  specifications  that  prescribe  the  number  of  maintenance  visits  per 
year.  These  specifications  also  limit  the  number  of  maintenance  actions  that  require  or 
cause  shut  down  of  the  system.  In  seeking  to  attain  the  required  level  of  system  reliability, 
the  product  developer  has  the  freedom  to  vary  only  the  level  of  redundancy  in  the  system, 
leading  to  the  potential  for  suboptimal  system  LCC. 

The  methodology  developed  in  this  project  supports  analyzing  such  trade-offs.  The 
methodology  was  developed  by  researchers  from  the  University  of  Maryland  and  IDA 
working  with  personnel  from  Westinghouse  Electric  and  Texas  Instruments. 

At  the  same  time  the  methodology  was  developed,  the  CALCE  Center  researchers 
developed  software  that  supports  a  product  development  team  in  executing  the 
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methodology.  This  software,  developed  in  collaboration  with  IDA,  Westinghouse  Electric, 
and  Texas  Instruments,  is  an  extension  of  the  existing  CALCE  software  package,  which  is 
supplied  to  center  members.  The  extension  incorporates  many  existing  CALCE  software 
capabilities  such  as  the  parts  data  base  and  graphics  displays.  New  features  incorporated  in 
support  of  the  methodology  include  the  capability  to  calculate  the  reliability  of  redundant 
systems  with  repair  and  the  capability  to  estimate  acquisition  cost  and  life  cycle  maintenance 
visit  costs  for  systems  with  redundant  parts. 

E.  DEMONSTRATION  AND  EVALUATION 

A  demonstration  and  evaluation  of  the  methodology  took  place  on  September  20, 
1989,  at  the  University  of  Maryland.  Representatives  from  IDA,  the  Air  Force  Human 
Resources  Laboratory  (AFHRL),  the  University  of  Maryland,  Texas  Instruments,  and 
Westinghouse  Electric  attended.  The  demonstration  consisted  of  a  presentation  by  Dr. 
Pecht  on  the  theory  of  redundant  systems  with  repair  (which  is  the  theoretical  basis  for  the 
methodology),  a  demonstration  of  how  the  computer  is  used  to  support  the  group 
deliberations,  a  working  session  in  which  redundancy  and  scheduled  maintenance  were 
assessed  for  a  subassembly  of  the  ARSR-4,  and  a  discussion  in  which  the  methodology 
was  evaluated  and  recommendations  for  future  research  and  enhancements  were  given. 
The  following  paragraphs  summarize  these  recommendations. 

1 .  Identifying  Where  to  Add  Redundancy  in  the  System 

In  using  the  methodology  developed  in  this  project,  a  product  development  team 
must  rely  on  the  expertise  of  members  in  determining  which  system  elements  to  make 
redundant.  An  analytical  solution  to  the  problem  of  identifying  locations  and  levels  of 
redundancy  to  minimize  LCC  seems  unlikely,  especially  if  the  entire  radar  system  is 
considered.  However,  rules  could  be  developed  to  guide  the  product  development  team  in 
selecting  where  to  place  redundancies,  leading  to  improvements  in  the  resulting  designs  and 
a  more  efficient  product  development  process.  Development  of  such  rules  should  be  the 
topic  of  future  research  projects. 

2.  Initiating  and  Managing  Trade  Studies 

As  additional  capabilities  are  added,  to  the  computer  support  available  to  the  product 
development  team,  the  number  of  potential  excursions  and  trade-off  analyses  rapidly 
expands,  and  team  members  may  spend  valuable  time  on  issues  with  limited  benefits  (or 
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analyze  less  viable  trade-offs).  A  structured  way  to  identify  specific  trade-off  analyses  to 
be  conducted,  based  cm  experience  and  judgment,  is  needed  to  best  focus  team  efforts. 

3.  Addressing  Ramifications  of  Increased  Redundancy 

A  number  of  side  effects  are  generated  when  additional  redundancies  are  added  to  a 
system.  At  present,  the  methodology  does  not  consider  these  effects.  Additional  research 
is  needed  to  allow  such  effects  to  be  addressed  within  the  context  of  the  current 
methodology. 

These  effects  include 

•  Increased  system  power  requirements  when  additional  active  redundancy  is 
added  (resulting  in  degradations  in  reliability) 

•  Increased  size  and  weight  of  the  system  resulting  from  added  redundant 
components 

•  Increased  system  complexity  --  resulting  in  increased  development  time  and 
cost 

•  Increased  support  equipment  required  to  handle  redundancy  (switching/voting 
devices,  interconnections,  environmental  conditioning),  leading  to  increased 
cost  and  degradation  of  reliability 

•  Increased  difficulties  in  fault  detection  and  isolation  resulting  from  redundancy, 
leading  to  increased  logistic  support  costs  due  to  requirements  for  additional 
spares  and  manpower. 

4.  Assessing  Life  Cycle  Cost 

The  methodology  now  handles  LCC  through  use  of  an  LCC  indicator  comprising 
separate  estimates  for  parts  and  maintenance  costs.  The  industry  participants  viewed  this 
approach  as  useful  and  appropriate  for  assessing  LCC.  The  accuracy  of  individual 
components  of  the  indicator,  however,  could  be  improved. 

For  example,  the  methodology  now  uses  total  parts  cost  to  represent  the  acquisition 
cost  of  the  system;  however,  the  cost  of  the  parts  is  only  a  small  portion  of  the  total 
acquisition  cost  The  large  expenditures  for  engineering  man-hours  and  overhead  are 
ignored.  Thus,  one  enhancement  to  the  methodology  could  be  developing  a  more  realistic 
acquisition  cost  indicator. 

The  support  cost  indicator,  the  maintenance  visit  cost,  could  be  modified  to  more 
accurately  reflect  the  support  costs  by  considering  items  such  as  levels  of  maintenance 
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(with  considerations  of,  for  example,  the  relative  costs  of  built-in-test  versus  external  test 
equipment). 

While  more  realistic  cost  indicators  are  desirable,  the  industry  representatives 
strongly  recommended  that  a  full  LCC  model  not  be  incorporated  into  the  analysis. 
Industry  acceptance  of  the  validity  of  such  models  is  not  sufficient  to  justify  their  use  in  the 
methodology. 

5.  Recording  Team  Activities 

An  audit  trail  of  the  various  alternatives  considered  by  the  product  development 
team  during  the  trade-off  process  should  be  provided.  A  way  to  save  alternative 
configurations  and  their  associated  analysis  results  is  needed.  Maintaining  the  history  of  a 
small  subsystem  would  not  necessarily  require  significant  computing  resources.  If  the 
entire  radar  is  modeled,  maintaining  an  audit  trail  could  require  significant  amounts  of 
storage  and  entail  significant  information  management  problems. 

6.  Assessing  the  Entire  Radar 

While  the  methodology  demonstrates  the  concept  of  performing  trade-offs  of 
redundancy  versus  maintenance  visits,  for  such  trade-offs  to  be  realistic,  the  entire  radar 
system  must  be  modeled.  This  need  raises  issues  related  to  increasing  the  computer 
support  capabilities  to  handle  the  level  of  detail  required  to  model  the  entire  system.  To 
address  issues  such  as  assessing  the  relative  benefits  of  changing  the  quality  level  of  a 
certain  part,  which  may  appear  500  times  in  a  number  of  separate  subsystems,  additional 
computer  support  capabilities  are  needed.  These  capabilities  are  also  needed  because  the 
builder  of  the  radar  warrants  the  entire  system  and  is  interested  in  the  reliability  and 
maintenance  cost  of  the  total  system,  not  just  a  small  subsystem  as  was  used  in  the 
demonstration. 

F.  FINDINGS  AND  RECOMMENDATIONS 

This  project  has  successfully  demonstrated  how  the  conceptual  approach  of  DFA 
can  be  applied  to  design  for  supportability.  The  findings  and  research  opportunities 
identified  during  this  project  have  been  grouped  into  three  categories  and  are  presented  in 
the  following  sections. 
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1 .  Organizing  and  Managing  Teams 

Having  a  core  product  development  team  that  charters  specialty  teams  as  needed 
was  the  IDA  research  team's  vision  of  how  product  development  teams  could  be  organized. 
The  organizational  issues  involved  with  creating  and  managing  concurrent  engineering 
teams,  and  in  particular,  the  activities  of  multiple  teams,  warrants  a  substantial  research 
effort.  A  core  team,  like  the  one  envisioned  for  this  project,  could  coordinate  the  work  of 
the  other  teams,  each  of  which  would  be  investigating  certain  problems  and  conducting 
trade  studies.  However,  one  team  could  conduct  a  study  indicating  that  a  certain  course  of 
action  should  be  followed  to  realize  certain  benefits,  yet  this  action  may  create  problems  for 
another  team  that  is  trying  to  achieve  other  goals.  Such  conflicts  must  be  resolved. 

The  most  common  way  resolving  such  conflicts  is  through  design  review  boards 
(which  often  meet  after  design  decisions  are  made)  and  ultimately,  by  autocratic  decisions 
made  by  engineering  management.  This  approach  often  leads  to  failure  to  identify  and 
resolve  major  conflicts  until  a  stage  in  the  design  process  in  which  design  changes  are  very 
expensive.  A  better  way  is  needed. 

During  the  demonstration  of  the  methodology  developed  in  this  project,  the  group 
interactions  were  completely  unstructured.  However,  structured  group  problem  solving 
methodologies  have  been  shown  to  make  group  problem  solving  more  efficient. 
Identifying  promising  structured  group  problem  solving  methodologies  for  concurrent 
engineering  is  another  area  for  research. 

This  project  has  shown  that  government  requirements,  such  as  specifying  the 
number  of  maintenance  visits,  can  place  unnecessary  constraints  on  a  product  development 
team.  This  type  of  limitation  could  result  in  products  with  LCC  higher  than  necessary.  An 
approach  to  product  acquisition  in  which  the  requirements  are  jointly  developed  by  a  team 
consisting  of  both  government  and  industry  personnel  would  result  in  requirements  that  do 
not  unnecessarily  restrict  the  design  freedom  of  the  product  development  team.  The 
research  team  did  not  consider  any  legal  or  political  issues  associated  with  using  such  an 
approach  to  acquisition.  These  issues  would  have  to  be  addressed  before  such  an  approach 
to  acquisition  could  be  implemented 

2 .  Computer-Aided  Group  Problem  Solving 

The  proper  role  of  the  computer  in  support  of  group  problem  solving  is  an  area  of 
growing  research.  Approaches  range  from  the  group  sharing  a  single  computer  during  the 
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meeting  (as  was  done  in  this  project)  to  providing  a  separate  computer  for  each  attendee. 
Other  areas  of  research  are  concerned  with  supporting  the  group  when  they  are  working  in 
a  distributed  environment 

This  project  demonstrated  that  software  originally  designed  for  a  single  user  can  be 
used  in  a  group  setting.  Contrary  to  claims  made  by  some  researchers,  specific  group- 
oriented  software  is  not  necessarily  required.  The  use  of  other  single-user  software  in 
group  settings  should  be  explored. 

How  the  computer  support  for  the  team  is  developed  is  an  open  issue.  One 
approach  is  to  let  the  product  development  team  build  its  own  computer  models  using 
spreadsheets  or  similar  software  shells.  One  advantage  of  models  built  by  the  team  is  that 
the  team  members  will  be  confident  of  the  model's  accuracy,  since  the  team  itself  verified 
the  validity  of  the  approach  used  in  the  model. 

3.  Design  for  Maintainability 

The  final  area  that  requires  additional  research  is  a  developing  design  for 
maintainability  methodologies  and  tools.  Significant  gaps  exist  in  the  field  of  design  for 
maintainability.  The  review  of  the  research  literature  found  a  lack  of  consensus  in  the 
research  community  on  the  definition  of  maintainability  and  how  to  design  for 
maintainability.  Many  of  the  industry  maintainability  specialists  interviewed  during  this 
study  defined  designing  for  maintainability  as  calculating  the  Military  Handbook  (MIL- 
HDBK)  472  attributes  of  a  design,  such  as  mean  time  to  repair  (MTTR). 

The  available  measurements  of  maintainability  have  not  kept  pace  with  advancing 
technology.  For  example,  the  techniques  proposed  in  MIL-HDBK  472  do  not  properly 
handle  designs  in  which  high  reliability  is  achieved  through  use  of  redundancy  with  repair. 
In  such  situations,  scheduled  maintenance  is  the  key  element- not  corrective  maintenance, 
which  is  the  only  item  addressed  in  the  handbook. 

G.  FUTURE  DIRECTIONS 

The  methodology  developed  during  the  course  of  this  project  only  begins  to  address 
the  many  considerations  relating  to  incorporation  of  supportability  into  the  product 
development  process.  Much  remains  to  be  done.  However,  the  results  of  this  project, 
which  was  limited  in  its  scope  and  funding,  clearly  indicate  that  there  is  great  potential  for 
improving  development  processes  through  use  of  relatively  simple  approaches  to  aid 
product  development  teams.  The  conceptual  approach  of  Boothroyd  and  Dewhurst,  which 
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has  been  proven  successful  in  improving  the  ease  of  assembly  of  designs,  and  has  been 
applied  to  limited  aspects  of  supportability  in  this  project,  can  also  be  applied  to  many  other 
issues  that  must  be  addressed  if  the  goals  of  improved  quality,  reduced  cost,  and  shortened 
development  lead  time  are  to  be  attained.  Moreover,  such  applications  need  not  be  costly  to 
develop.  The  relative  benefits  from  taking  such  an  approach  on  major  weapon  system 
acquisition  programs  are  likely  to  be  great 
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I.  INTRODUCTION 


i 

This  paper  presents  the  results  of  a  research  project  that  had  the  objective  of 
demonstrating  how  the  conceptual  approach  of  the  Boothroyd  and  Dewhurst  Design  for 
Assembly  (DFA)  process  could  be  applied  to  developing  products  that  were  not  only  easy 
to  assemble  in  the  factory,  but  also  more  easily  supported  in  the  field.  This  conceptual 
approach  consists  of  five  elements: 

•  Product  development  by  a  multifunctional  team 

•  Relative  assessment  of  alternative  designs  with  a  metric 

•  Training  in  the  theoretical  basis  underlying  the  metric 

•  A  specific  procedure  by  which  alternative  designs  are  created  and  evaluated 

•  Computer  support  for  the  team  during  product  development  meetings. 

In  this  project,  a  specific  methodology  was  developed  that  allows  a  product 
development  team  using  this  conceptual  approach  to  make  system-level  trade-offs  between 
redundant  part  selection  and  scheduled  maintenance  visits  to  achieve  low  life  cycle  cost 
(LCC)  and  high  operational  readiness  of  the  resulting  system.  This  methodology  was 
demonstrated  for  a  subsystem  of  a  ground- based  radar  and  evaluated  by  participants  in  the 
demonstration. 

A.  BACKGROUND 

Unified  Life  Cycle  Engineering  (ULCE)  was  an  Air  Force  Project  Forecast  II 
Research  and  Development  program  with  the  goal  of  developing 

A  design  engineering  environment  in  which  computer-aided  design 
technology  is  used  to  continually  assess  and  improve  the  quality  of  a 
product  during  the  active  design  phases  as  well  as  throughout  its  entire  life 
cycle  by  integrating  and  optimizing  design  attributes  for  producibility  and 
supportability  with  design  attributes  for  performance,  cost,  and  schedule. 

[Ref.  2] 

During  Fiscal  Year  1988,  a  research  team  at  IDA  performed  a  study  under  the 
auspices  of  the  ULCE  Program  titled  Measurement  Issues  in  Unified  Life  Cycle 
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Engineering.  As  pan  of  this  study,  the  research  team  investigated  various  techniques  used 
by  industry  to  evaluate  producibility  and  supportability  in  the  early  phases  of  the  product 
development  process.  This  investigation  revealed  that  the  trend  in  industry  is  toward  a 
concurrent  engineering  approach  in  which  product  development  is  accomplished  by  a 
multifunctional  team  including  specialists  from  all  relevant  departments  in  the  company 
(e.g.  design,  manufacturing,  finance,  marketing,  and  product  support).  Group  problem 
solving  is  an  activity  that  underlies  much  of  the  work  of  such  product  development  teams. 

Because  the  primary  thesis  of  ULCE  is  that  use  of  computers  can  facilitate  the 
accomplishment  of  a  life  cycle  approach  to  engineering,  a  question  naturally  arose  as  to 
what  extent  computers  were  being  used  by  industry  to  facilitate  the  group  problem  solving 
process  needed  in  concurrent  engineering. 

In  an  attempt  to  answer  this  question,  the  study  team  surveyed  both  current  industry 
multifunctional  product  development  team  practices  and  current  computer-aided  group 
problem  solving  methodologies  and  technologies  [Ref.  3].  While  the  latter  methodologies 
and  technologies  offer  potentially  great  benefits  to  product  development  teams,  the  study 
team  observed  little  use  of  such  techniques  by  industry  product  development  teams.  This 
finding  prompted  a  study  team  recommendation  that  the  ULCE  program  be  broadened  to 
consider  research  in  applying  computer-aided  group  problem  solving  techniques  to  product  , 

development  processes  [Ref.  3]. 

One  notable  exception  to  this  finding  was  the  Boothroyd-Dewhurst  DFA 
methodology,  which  has  been  successfully  used  in  many  companies  to  support  concurrent 
engineering  teams  in  designing  products  that  can  be  easily  assembled  in  the  factory.  Based  i 

on  the  success  of  DFA,  the  study  team  hypothesized  that  the  conceptual  approach  of 
Boothroyd  and  Dewhurst  could  also  be  applied  to  design  for  supportability.  This 
hypothesis  formed  the  basis  of  the  research  project  described  in  the  remainder  of  this  paper. 

B  .  ORGANIZATION  OF  THE  REPORT 

Chapter  II  contains  a  project  overview  that  describes  DFA  and  outlines  the  approach 
taken  by  the  research  team  in  arriving  at  the  methodology  developed  in  this  project. 

Chapter  III  describes  the  methodology  developed  during  this  research  project.  Chapter  IV  t 

details  the  demonstration  of  this  methodology  and  its  evaluation  by  industry  participants  in 
the  demonstration.  Chapter  V  presents  recommendations  for  further  research  based  on  the 
findings  of  the  research  team  and  on  comments  from  industry. 
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Appendix  A  contains  a  discussion  of  historical  approaches  to  consideration  of 
maintainability  in  the  design  process  and  includes  various  definitions  of  maintainability  and 
maintainability  design  rules  and  guidelines.  Appendix  B  contains  an  annotated 
bibliography  of  research  papers,  articles,  and  books  treating  issues  of  maintainability  in 
electronics  design.  Appendix  C  describes  the  computer  support  environment  that  allows 
efficient  execution  of  the  methodology  developed  in  this  project.  Also  included  in  this 
appendix  are  details  of  the  equations  underlying  the  metrics  that  are  used  in  the 
methodology. 
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n.  PROJECT  OVERVIEW 


The  goal  of  this  project  was  to  demonstrate  that  the  conceptual  approach  taken  by 
Boothroyd  and  Dewhurst  in  their  DFA  process  can  also  be  applied  to  developing  more 
supportable  products.  To  accomplish  this,  a  methodology  was  developed  that  addresses 
considerations  of  reliability,  maintenance  scheduling,  and  logistics  support  for  a  ground- 
based  radar  system.  This  methodology  provides  analyses  that  facilitate  development  of 
alternative  configurations  of  the  radar  system  that  exhibit  low  LCC  while  meeting  minimum 
requirements  for  system  reliability.  In  a  parallel  effort,  computer  software  was  developed 
that  supports  the  product  development  team  in  calculating  the  metrics  needed  for  the 
methodology. 

This  chapter  provides  an  overview  of  the  conceptual  approach  of  Boothroyd  and 
Dewhurst  and  outlines  the  specific  research  tasks  and  findings  that  lead  to  the  development 
of  the  methodology  described  in  Chapter  HI. 

A.  BOOTHROYD  AND  DEWHURST  DESIGN  FOR  ASSEMBLY 

Boothroyd  and  Dewhurst  have  developed  a  methodology  that  supports  a  product 
development  team  in  designing  products  that  are  easy  to  assemble  [Ref.  4].  The  conceptual 
approach  of  the  DFA  methodology  consists  of  the  following  five  elements. 

•  Product  development  by  a  multifunctional  team 

•  Relative  assessment  of  alternative  designs  with  a  metric 

•  Training  in  fundamentals  of  the  methodology  and  underlying  metric 

•  A  specific  procedure  by  which  alternative  designs  are  created 

•  Computer  support  for  the  team  during  product  development  meetings. 

Bart  Huthwaite,  a  well  known  instructor  in  the  DFA  methodology,  emphasizes  that 
the  team  philosophy  is  essential  for  successful  implementation  of  DFM  [Ref.  5].  A  team 
composed  of  members  from  all  of  the  departments  of  the  company  that  are  concerned  with 
the  product  under  development  ensures  that  each  department's  perspective  is  considered. 
More  ideas  can  be  generated  when  the  team  works  together  to  recognize  weak  points  in  the 
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design.  The  team  members'  creativity  is  stimulated  by  shared  ideas.  A  synergy  develops 
within  the  team. 

A  quantitative  measure  (or  metric)  that  is  used  as  a  basis  for  comparison  of 
alternative  designs  is  a  key  element  of  the  DFA  approach.  Computation  of  the  DFA  metric 
begins  with  estimating  the  total  assembly  time  for  the  design.  To  compute  this  time,  the 
assembly  sequence,  geometric  features,  and  rough  dimensions  for  the  current  design  must 
be  known.  Using  this  information,  the  design  is  rated  in  terms  of  the  estimated  time  that 
will  be  required  for  part  handling  and  orientation  and  for  part  insertion  and  securing,  and 
these  ratings  are  used  to  calculate  the  total  assembly  time. 

Next,  the  assembly  time  for  an  ideal  design  having  the  theoretical  minimum  number 
of  parts  is  calculated.  This  ideal  design  will  generally  not  be  feasible  due  to  constraints 
such  as  the  economics  of  manufacture  or  unavailability  of  specialized  manufacturing 
equipment  to  make  the  more  complicated  parts  needed  in  a  minimum-part-count  design 
[Ref.  4].  Thus  the  ideal  design  cannot  usually  be  used  as  the  solution  to  the  design 
problem. 

An  assembly  efficiency  for  the  current  design  is  then  computed  by  dividing  the 
estimated  assembly  time  for  the  theoretical  minimum-part-count  design  by  that  of  the 
current  design.  This  assembly  efficiency,  expressed  as  a  percentage,  is  used  as  the  metric 
when  evaluating  alternative  designs.  Designs  with  higher  assembly  efficiencies  are  to  be 
preferred,  all  other  things  being  equal,  to  those  with  lower  assembly  efficiencies. 

The  assembly  efficiency  metric  is  based  largely  on  the  judgment  of  team  members. 
It  must  be  considered  a  relative,  rather  than  absolute,  measure.  Assembly  efficiencies 
should  only  be  compared  with  other  assembly  efficiencies  calculated  by  the  same  product 
development  team. 

The  theoretical  basis  of  the  assembly  efficiency  is  a  set  of  12  generic  guidelines 
[Ref.  5].  The  guidelines  and  use  of  the  metric,  including  the  proper  interpretation  of  the 
assembly  time  estimation  attributes,  are  taught  to  the  team  before  design  alternatives  are 
generated. 

The  DFA  procedure  for  generating  alternative  designs  is 

1 .  Calculate  the  assembly  time  of  the  current  design.  (A  baseline  design  must  be 
available  to  begin  this  procedure.) 

2.  Based  on  the  function  of  each  part  of  the  current  design,  calculate  the  ideal 
assembly  time  for  a  design  that  has  a  theoretical  minimum  number  of  parts. 
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3 .  Calculate  an  assembly  efficiency  rating  for  the  current  design  as  compared  with 
the  ideal  design. 

4.  Using  judgment  based  on  the  design  for  assembly  guidelines  and  weak  points 
of  the  current  design  as  identified  by  the  metric,  modify  the  current  design  to 
increase  the  assembly  efficiency. 

5 .  Continue  this  procedure  of  modifying  and  assessing  the  resulting  design  until 
the  product  development  team  has  identified  a  preferred  design  or  until  no  more 
time  remains  for  design  activities. 

While  the  team  is  determining  the  ratings  and  establishing  the  theoretical  minimum  number 
of  parts,  team  members  share  knowledge  and  insights.  Creativity  is  stimulated,  and 
innovative  solutions  are  proposed.  The  group  identifies  problems  with  the  current  design 
and  continually  explores  ideas  for  improvement 

DFA  software  allows  the  product  development  team  to  calculate  the  assembly  times 
and  assembly  efficiencies  for  alternative  designs.  This  software  resides  on  a 
microcomputer  that  is  operated  by  a  designated  team  member.  The  computer  screen  is 
made  visible  to  all  team  members.  While  the  assembly  time  and  assembly  efficiencies 
could  be  calculated  by  hand,  the  computer  can  perform  the  calculations  faster-a  valuable 
feature  because  the  key  to  consistent  measurements  made  by  a  group  is  rapid  iteration  [Ref. 
5]. 

Using  a  team  for  product  development  is  being  widely  promoted;  however, 
bringing  together  a  team  of  people  from  different  departments  with  a  range  of  skills  to  work 
for  a  common  goal  is  not  an  easy  task.  Ignoring  the  logistical  concerns,  a  fundamental 
problem  is  communication.  A  product  development  methodology  such  as  DFA  can  provide 
the  common  language  needed  for  successful  product  development  team  interaction  [Ref.  6]. 
DFA  enhances  the  creativity  and  experience  of  the  team  members,  helps  the  team  reach 
consensus,  and  enables  the  team  members  to  make  estimates  when  exact  measures  are  not 
available  [Ref.  5].  The  process  of  using  DFA  is  considered  as  important  as  the  analytical 
results  derived  from  its  use.  The  ultimate  goal  of  the  DFA  methodology  is  not  to  calculate 
the  assembly  efficiency  but  to  improve  the  design. 

In  view  of  the  importance  of  the  process  embodied  in  the  DFA  approach,  the 
research  team  hypothesized  that  this  process  could  be  applied  to  design  for  attributes  other 
than  ease  of  assembly.  In  particular,  supportability  is  a  design  characteristic  of 
considerable  interest  to  DoD  that  should  receive  consideration  early  in  the  design  process. 
As  a  first  step  in  demonstrating  how  the  DFA  process  could  be  extended  to  supportability. 
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the  research  team  undertook  to  ascertain  the  current  state  of  the  art  in  methodologies  for 
measuring  supportability  and  for  designing  improved  supportability. 

B .  LITERATURE  REVIEW 

An  extensive  literature  review  was  initiated  at  the  beginning  of  the  task  to  identify 
existing  techniques  for  defining,  measuring,  and  designing  for  supportability.  The  goal  of 
this  broad  review  was  to  identify  aspects  of  supportability  to  focus  on.  As  a  result,  the 
research  team,  in  cooperation  with  the  sponsor,  decided  to  limit  aspects  of  supportability 
considered  in  this  investigation  to  maintainability,  reliability,  and  logistics  support,  in  this 
order  of  priority. 

Since  maintainability  received  the  highest  priority,  the  research  team  refined  the 
literature  review  to  focus  on  maintainability  and  identify  methodologies  and  guidelines  used 
for  design  for  maintainability.  The  results  of  this  refined  review  are  included  in 
Appendices  A  and  B.  An  index  of  the  complete  supportability  file  is  also  available  from 
EDA. 

Incorporating  maintainability  considerations  early  in  the  design  process  through  the 
team  approach  is  not  a  new  concept.  In  1956,  Milton  J.  Marcus  of  the  Human  Engineering 
Laboratory,  Rome  Air  Development  Center  (RADC),  made  the  following  comments  at  the 
Ease  of  Maintainability  Conference  [Ref.  7]: 

Another  factor  relating  to  the  inclusion  of  maintenance  considerations  early 
in  the  equipment  development  process  is  the  position  of  maintenance  near 
the  bottom  of  the  hierarchy  of  design  requirements,  which  has  contributed 
to  the  growth  of  the  problem  to  its  present  magnitude.  Equipments  must  be 
planned  to  simplify  or  eliminate  maintenance  procedures.  This  requires 
team-type  efforts,  with  the  design  engineer  and  the  engineering 
psychologist  working  together. 

Developing  a  generic  tool  to  aid  teams  in  designing  for  maintainability  is,  however, 
problematic.  The  literature  review  revealed  that  no  universally  accepted  definition  of 
maintainability  exists.  No  concise,  manageable  set  of  generic  guidelines  for  design  for 
maintainability  could  be  gleaned  from  the  extensive  lists  found  in  various  government  and 
industry  references.  The  research  team  determined  that  design  for  maintainability 
guidelines  must  be  specifically  tailored  to  the  product  being  developed.  This  finding 
prompted  the  research  team  to  further  restrict  its  attention  to  a  specific  design  problem. 

Maintainability,  reliability,  and  logistics  support,  are  all  related  and  should  be 
considered  together  in  designing  a  system  for  supportability.  To  achieve  a  good  design-in 


terms  of  supportability-the  design  team  must  be  able  to  perform  trade-offs  between  these 
attributes  of  the  design.  To  more  specifically  identify  the  kinds  of  trade-offs  that  would  be 
appropriate  for  consideration  in  this  project,  the  research  team  collaborated  with  both 
academia  and  industry. 

C .  COLLABORATION  WITH  ACADEMIA  AND  INDUSTRY 

Through  a  cooperative  arrangement  with  the  University  of  Maryland  Center  for 
Computer-Aided  Life  Cycle  Engineering  (CALCE),  the  research  team  collaborated  with 
academia  and  industry.  This  center,  an  industry-university  cooperative  research  center 
sponsored  by  the  National  Science  Foundation,  has  as  its  primary  focus  development  of 
new  techniques  for  designing  electronic  products  for  reliability,  maintainability,  and 
supportability.  The  CALCE  center  is  the  only  center  of  its  kind  in  the  country  that  is 
focusing  on  design  for  supportability  of  electronics.  Its  director.  Dr.  Michael  Pecht,  is  a 
nationally  recognized  expert  in  design  of  electronic  systems  for  supportability. 

Under  the  arrangement  with  the  CALCE  center,  the  University  of  Maryland  was 
given  a  research  grant  by  IDA  to  provide  technical  assistance  in  developing  the 
methodology  for  this  project.  In  a  parallel  effort,  the  CALCE  center  undertook  an 
internally  funded  project  to  develop  software  to  support  a  product  development  team  in 
executing  the  methodology. 

A  number  of  major  industrial  defense  electronics  suppliers  are  members  of  the 
CALCE  center— Westinghouse  Electric,  Texas  Instruments,  Digital  Equipment  Corporation, 
Northrop,  General  Electric,  Allied  Signal,  and  General  Dynamics.  Westinghouse  Electric 
and  Texas  Instruments  agreed  to  provide  technical  support  to  EDA  in  the  development  of  the 
methodology  and  to  participate  in  a  demonstration  and  evaluation  of  the  methodology  at  the 
conclusion  of  the  project. 

D.  SYSTEM  SELECTION 

The  ARSR-4  was  selected  as  the  baseline  system  to  be  used  for  development  of  the 
methodology.  The  ARSR-4  is  a  ground-based,  long-range  3-D  radar  currently  under 
development  by  Westinghouse  Electric.  The  system  is  being  designed  to  meet  the  air  traffic 
control  and  air  defense  sensor  requirements  of  the  Federal  Aviation  Administration  (FAA) 
and  the  U.S.  Air  Force’s  Joint  Surveillance  System  (JSS).  The  ARSR-4  was  selected  for 
the  methodology  development  because  the  design  information  (and  designers)  needed  for 
the  methodology  was  readily  available,  and  Westinghouse  Electric  was  willing  to  supply 


this  information  to  the  CALCE  Center.  In  addition,  considerations  of  supportabiiity  are 
playing  a  significant  role  in  the  design  of  the  ARSR-4. 


E.  ARSR-4  SUPPORT  ABILITY  ISSUES 

The  ARSR-4  is  being  designed  by  Westinghouse  Electric  for  unattended  operation 
and  low  LCC.  The  only  support  equipment  it  will  require  is  a  limited  number  of  tools  on 
site  and  equipment  already  part  of  the  FAA/Air  Force  inventory.  The  use  of  redundant 
parts  in  a  system  allows  failure  of  one  of  the  parts  without  failure  of  tl'e  entire  system. 
Thus,  to  achieve  high  reliability  and  allow  continuous  operation,  redundancy  is  used 
extensively  in  the  design  of  this  system.  Scheduled  maintenance  visits  are  also  used  to 
enhance  reliability  through  periodic  replacement  of  failed  redundant  components. 

These  approaches  to  enhancing  reliability  are  not  without  cost,  however. 
Increasing  the  number  of  redundant  components  increases  system  acquisition  cost,  while 
increasing  the  frequency  of  maintenance  visits  increases  system  logistics  support  cost.  If  a 
given  level  of  system  reliability  is  required,  increasing  redundancy  allows  the  frequency  of 
maintenance  visits  to  be  reduced,  and  conversely,  increasing  the  frequency  of  maintenance 
visits  allows  redundancy  to  be  reduced.  The  net  LCC  impact  of  changing  redundancy  and 
maintenance  visit  frequency  will  depend  on  the  relative  magnitudes  of  such  factors  as  the 
cost  of  the  parts  being  made  redundant,  manpower  and  transportation  costs  associated  with 
maintenance  visits,  and  spares  costs. 

To  minimize  the  total  system  LCC,  which  includes  both  acquisition  and  support 
costs,  a  method  for  obtaining  the  proper  balance  between  redundancy  and  maintenance  visit 
frequency  is  needed.  To  obtain  such  a  balance,  the  product  development  team  needs  the 
freedom  to  vary  the  level  of  redundancy  and  the  frequency  of  maintenance  visits,  and  the 
capability  to  estimate  the  LCC  impact  of  such  changes. 

In  the  current  government  acquisition  process  for  the  ARSR-4,  the  product 
developer  was  given  specifications  that  prescribe  the  number  of  maintenance  visits  per 
year.  These  specifications  also  limit  the  number  of  maintenance  actions  that  require  or 
cause  shut  down  of  the  system.  In  seeking  to  attain  the  required  level  of  system  reliability, 
the  product  developer  has  the  freedom  to  vary  only  the  level  of  redundancy  in  the  system, 
leading  to  the  potential  for  suboptimal  system  LCC. 
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F .  SCENARIO  FOR  METHODOLOGY  DEVELOPMENT 


In  order  to  place  the  methodology  in  context,  the  following  scenario  was  created.  It 
is  assumed  that  at  some  point  in  the  future  a  major  technological  advance  has  occurred  that 
has  initiated  development  of  the  next  generation  of  the  ground-based  3-D  air  surveillance 
radar,  which  will  be  called  the  ARSR-5.  It  is  also  assumed  that  by  the  time  of  the  ARSR-5 
procurement,  the  Department  of  Defense  (DoD)  has  adopted  the  concurrent  engineering 
approach  to  system  acquisition.  Thus,  the  concept  exploration  phase  of  the  acquisition 
cycle,  where  requirements  are  set,  is  now  conducted  as  a  multifunctional  product 
development  team  effort  with  representatives  from  DoD  (the  customer)  and  design, 
manufacturing,  and  supportability  engineers  from  potential  contractors.  For  the  ARSR-5 
procurement,  minimizing  LCC  while  maximizing  operational  readiness  is  a  key  design 
goal.  This  goal  must  be  addressed  from  the  outset  of  the  systems  engineering  process  for 
the  ARSR-5.  The  number  of  maintenance  visits  is  no  longer  government  specified  but  is  a 
design  variable  that  can  be  traded  off  with  the  amount  of  redundancy  used  in  the  system 
design.  The  methodology  developed  during  this  project  allows  a  product  development 
team  to  conduct  such  trade-off  studies. 

G.  COMPUTER  SUPPORT 

At  the  same  time  the  methodology  was  developed,  the  CALCE  Center  researchers 
developed  software  that  supports  calculating  the  metrics  needed  for  the  methodology.  This 
software,  developed  in  collaboration  with  IDA,  Westinghouse  Electric,  and  Texas 
Instruments,  is  an  extension  of  the  existing  CALCE  software  package,  which  is  supplied  to 
center  members.  The  extension  incorporates  many  existing  CALCE  software  capabilities, 
such  as  the  parts  data  base  and  graphics  displays.  New  features  incorporated  in  support  of 
the  methodology  include  the  capability  to  estimate  the  reliability  of  redundant  systems  with 
repair  and  the  capability  to  calculate  system  cost  and  life  cycle  maintenance  visit  costs  for 
systems  with  redundant  parts. 

In  addition,  a  maintainability  prediction  capability  has  been  integrated  with  this 
methodology.  This  capability  allows  the  additional  consideration  of  the  relative  cost 
effectiveness  of  improving  the  maintainability  of  various  subsystems  or  components  of  the 
radar.  For  example,  the  benefits  of  reducing  the  removal  time  for  a  particular  line 
replaceable  unit  (LRU)  at  a  given  investment  cost  can  be  assessed  relative  to  the  overall 
expected  savings  in  system  LCC. 
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H.  DEMONSTRATION  AND  EVALUATION 


A  demonstration  and  evaluation  of  the  methodology  took  place  on  September  20, 
1989,  at  the  University  of  Maryland.  Representatives  from  IDA,  the  Air  Force  Human 
Resources  Laboratory  (AFHRL),  the  University  of  Maryland,  Texas  Instruments,  and 
Westinghouse  Electric  attended.  The  demonstration  consisted  of  a  presentation  by  Dr. 
Pecht  on  the  theory  of  redundant  systems  with  repair  (which  is  the  theoretical  basis  for  the 
methodology),  a  demonstration  of  how  the  computer  is  used  to  support  the  group 
deliberations,  a  working  session  in  which  redundancy  and  scheduled  maintenance  were 
assessed  for  a  subassembly  of  the  ARSR-4,  and  a  discussion  in  which  the  methodology 
was  evaluated  and  recommendations  for  future  research  and  enhancements  were  given. 
The  complete  results  of  the  demonstration  are  given  in  Chapter  IV. 


III.  METHODOLOGY 


The  methodology  developed  in  this  project  and  described  in  this  chapter  addresses 
the  issue  raised  in  the  preceding  chapter:  determining  an  appropriate  balance  between 
redundancy  in  the  radar  system  and  the  frequency  of  maintenance  visits  in  order  to  meet  a 
system  reliability  requirement  in  the  most  cost-effective  manner.  This  methodology  was 
developed  by  IDA  research  staff  members  working  with  researchers  at  the  CALCE  Center 
and  industry  representatives.  The  conceptual  approach  of  the  Boothroyd-Dewhurst  DFA 
process  was  used  as  the  basis  for  developing  the  methodology. 

A.  THEORETICAL  FOUNDATION  OF  THE  METHODOLOGY 

A  scheduled  maintenance  strategy  coupled  with  provision  for  redundancy  of  critical 
system  elements  offers  the  possibility  of  designing  a  system  for  near  failure-free  operation. 
In  the  methodology  developed  in  this  project,  it  is  assumed  that  during  each  scheduled 
maintenance  visit,  all  components  that  have  failed  since  the  last  visit  are  replaced  with 
functioning  components.  Increasing  the  frequency  of  such  visits  will  improve  the  system 
reliability,  provided  redundant  components  are  present.  If  no  redundant  components  are 
present,  and  exponential  failure  distributions  are  assumed  for  the  individual  components, 
then  scheduled  maintenance  will  not  affect  system  reliability. 

There  are  limits  as  to  how  much  system  reliability  can  be  increased  through  either 
increasing  maintenance  visit  frequency  or  increasing  the  numbers  of  redundant  components 
in  the  system.  The  limiting  case  in  terms  of  increasing  maintenance  visit  frequency  would 
be  a  situation  in  which  a  maintenance  crew  is  present  and  monitors  the  system 
continuously,  immediately  replacing  any  failed  component  with  a  functional  one.  This 
approach  cannot  guarantee  continuous,  failure  free  operation  of  the  system,  however, 
because  it  will  take  a  certain  amount  of  time  for  the  crew  to  remove  and  replace  a  failed 
component,  and  during  this  time  there  will  be  a  non-zero  probability  that  a  sufficient 
number  of  other  components  will  fail,  leading  to  a  system  failure. 

With  standby  redundancy,  in  which  additional  components  can  be  automatically 
activated  and  made  part  of  the  system  upon  failure  of  operating  components,  the  time 
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between  maintenance  visits  is  essentially  zero.  The  system  essentially  repairs  itself  in  real 
time.  However,  there  are  practical  limits  to  what  can  be  achieved  in  terms  of  improved 
reliability  through  this  approach.  Redundant  components  require  additional 
interconnections,  and  sensor  and  switching  mechanisms  are  needed  for  standby 
redundancies.  These  additional  elements  are  subject  to  failure,  and  their  hazard  rates  must 
be  considered  in  the  reliability  calculations.  Adding  additional  redundant  components  also 
complicates  fault  detection  and  isolation,  leading  to  increased  maintenance  times. 

In  a  series  system  (a  system  with  no  redundancies)  in  which  only  unscheduled 
maintenance  is  performed,  improving  the  reliability  of  the  system  will,  all  else  being  equal 
(in  particular,  assuming  the  cost  of  each  remove  and  replace  action,  in  terms  of  spares  cost, 
manpower,  etc.  is  unchanged),  lead  to  a  decrease  in  logistic  support  costs.  The  expected 
cost  of  maintenance  in  terms  of  manpower  and  spares  will  be  driven  by  the  number  of 
failures  that  will  be  experienced,  and  this  number  will  decrease  as  the  reliability  of  the 
system  is  increased.  In  the  case  of  a  system  with  redundancies  and  a  scheduled 
maintenance  strategy,  such  as  considered  in  this  project,  this  relationship  between  system 
reliability  and  logistic  support  costs  does  not  always  hold. 

For  a  given  maintenance  visit  frequency,  increasing  the  system  reliability  by 
increasing  redundancy  will  actually  increase  logistic  support  costs.  This  cost  increase  is 
because  in  the  interval  between  maintenance  visits,  more  components  in  the  system  can  fail 
(although  such  failures  may  not  lead  to  system  failure).  This  increase  in  the  expected 
number  of  failures  will  lead  to  an  increased  maintenance  workload  during  each  maintenance 
visit,  and  an  increase  in  spares  requirements  (under  the  assumption  that  all  failed 
components  are  replaced  during  each  visit.) 

If  achieving  a  given  level  of  system  reliability,  or  system  operational  availability  is 
desired,  then  increasing  the  amount  of  redundancy  can  be  accompanied  by  a  corresponding 
reduction  in  maintenance  visit  frequency.  Whether  the  net  effect  of  such  added  redundancy 
(after  visit  frequency  is  adjusted)  will  be  a  decrease  in  logistic  support  costs  will  depend  in 
a  complex  way  on  factors  such  as  the  cost  of  the  components  whose  redundancy  is  being 
increased,  their  reliabilities,  the  cost  of  maintenance  manpower,  and  fixed  costs  associated 
with  each  maintenance  visit. 

Because  of  these  factors,  achieving  an  optimal  balance  between  adding  redundancy 
and  ircreasing  the  frequency  of  maintenance  visits  is  a  non-trivial  analytical  problem.  An 
analytical  solution  to  this  problem  is  not  likely  to  be  achieved.  Incorporating  the  many 
complicating  factors  into  the  calculations  would  be  very  difficult  and  lead  to  considerable 
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uncertainty  regarding  the  validity  of  the  final  results.  Thus,  a  considerable  amount  of 
engineering  judgment  must  go  into  selecting  system  elements  to  be  made  redundant  in  order 
to  improve  reliability  at  a  reasonable  cost 

B .  MULTIFUNCTIONAL  PRODUCT  DEVELOPMENT  TEAMS 

For  this  project  it  is  assumed  that  a  core  team  is  formed  when  the  product 
development  is  initiated.  This  team  consists  of  members  from  all  of  the  relevant 
departments  in  the  organization,  as  well  as  customer  and  supplier  representatives.  As 
issues  arise  during  the  development,  this  team  charters  specialty  teams  to  address  the 
issues.  The  charter  includes  the  goals,  the  constraints,  and  the  system  the  specialty  team  is 
to  use  as  a  baseline. 

To  meet  the  DoD  goal  of  minimizing  field  support  costs  while  maximizing 
operational  readiness,  the  core  team  identifies  low  LCC  and  high  reliability  as  high  priority 
design  goals.  LCC  is  a  function  of  the  acquisition  costs  and  the  support  costs.  The  core 
team  recognizes  that  one  way  to  lower  LCC  while  still  meeting  reliability  requirements  is  to 
consider  adding  redundant  elements  to  the  radar  to  maintain  system  reliability,  while 
reducing  the  number  of  maintenance  visits  needed  per  year.  While  system  acquisition  costs 
are  increased  due  to  the  additional  parts  cost  for  redundant  components,  decreasing  the 
number  of  scheduled  maintenance  visits  decreases  the  system  support  costs.  Thus  the  core 
team  charters  a  specialty  team  to  address  this  trade-off  between  redundancy  and  scheduled 
maintenance  visits.  The  specialty  team  is  composed  of  design  engineers,  reliability  and 
maintainability  engineers,  and  a  DoD  (customer)  representative  of  the  program  manager  for 
the  specific  system.  The  team  could  also  include  other  specialty  engineers,  such  as 
producibility  engineers. 

As  a  result  of  other  team  efforts,  the  requirements  for  the  reliability  of  the  system  in 
series,  as  mean  time  between  failures  (MTBF),  and  system  reliability,  as  measured  by 
MTBCF,  are  determined  and  passed  on  to  this  specialty  team.  The  team’s  job  is  to  develop 
a  set  of  configurations  with  varying  amounts  of  redundancy  and  numbers  of  scheduled 
maintenance  visits  that  satisfy  these  reliability  requirements  and  exhibit  a  reasonably  low 
LCC. 

C .  METRIC  FOR  GOAL  ASSESSMENT 

In  the  methodology  developed  in  this  project,  the  metric  used  by  the  team  to  assess 
whether  the  goal  of  low  LCC  is  met  by  alternative  designs  is  called  an  LCC  indicator.  It 
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includes  some,  but  not  all,  of  those  costs  that  make  up  the  total  system  LCC.  In  particular, 
the  LCC  indicator  is  the  sum  of  a  proxy  for  system  support  cost  and  a  proxy  for  system 
acquisition  cost 

Since  all  failed  redundant  components  are  to  be  replaced  during  scheduled 
maintenance  visits,  the  spares  cost  is  calculated  based  on  the  failure  rates  of  the  elements 
and  is  included  in  the  cost  of  a  maintenance  visit  The  repair  cost  per  visit  and  the  travel 
cost  to  the  site  for  a  maintenance  visit  are  added  to  the  spares  cost  to  obtain  the  cost  per 
visit  The  cost  per  year  for  all  maintenance  visits  is  discounted  over  the  life  of  the  system 
to  obtain  the  proxy  for  total  support  cost  This  cost  is  added  to  the  total  parts  cost  which  is 
used  in  this  methodology  as  a  proxy  for  system  acquisition  cost  to  obtain  the  LCC 
indicator  value  for  a  given  system  configuration  (redundancy  specification  for  each  system 
element)  and  maintenance  visit  schedule. 

D.  TRAINING 

Once  the  specialty  team  assembles,  the  first  agenda  item  is  a  review  of  the  theory 
and  design  principles  behind  the  goals  and  the  analyses  required  for  the  trade-offs  to  be 
conducted  during  the  meeting.  The  principles  address  the  various  trade-offs  to  be 
considered  in  the  meeting  (redundancy  versus  maintenance  frequency)  and  should  specify 
useful  methods  of  achieving  the  specified  goals  within  the  given  constraints  (creative 
redundancy  modeling).  The  principles  are  stated  in  terms  that  every  member  of  the  product 
development  team  can  understand,  and  the  necessary  analysis  techniques  are  available  for 
review  during  the  session.  The  metrics  used  in  assessing  whether  the  alternative 
configurations  meet  the  goal  and  constraints  are  also  explained  to  the  team,  if  the  team 
members  were  not  involved  in  developing  the  metrics.  Verification  of  the  equations  and  the 
analyses  in  the  computer  software  is  provided  to  the  team.  After  reviewing  the  theoretical 
basis  of  the  system,  the  specialty  team  reviews  the  baseline  system  of  the  product  under 
development 

E.  GENERATION  OF  ALTERNATIVE  DESIGNS 

As  with  the  DFA  process,  a  baseline  design  is  needed  to  initiate  the  activities  of  the 
team.  Generation  of  alternative  designs  is  accomplished  by  changing  baseline  system 
element  attributes,  such  as  the  number  of  redundancies  of  an  element,  and  changing 
baseline  system  parameters,  such  as  the  frequency  of  scheduled  maintenance  visits. 
Modifications  are  made  only  with  the  consensus  of  the  team. 
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Once  an  alternative  has  been  modified,  element  attributes  and  die  system  parameters 
must  be  recalculated.  The  MTBF  for  the  series  configuration  of  the  design  is  checked  to 
determine  if  the  MTBF  requirement  is  violated.  If  the  MTBF  requirement  is  exceeded, 
another  modification  must  be  made  to  the  configuration  to  raise  the  MTBF  until  it  meets  the 
requirement  Once  the  MTBF  requirement  is  met  the  system  MTBCF  is  calculated  as  a 
function  of  the  number  of  maintenance  visits.  The  minimum  number  of  maintenance  visits 
required  to  achieve  the  specified  MTBCF  can  then  be  determined.  The  LCC  indicator  is 
calculated  once  the  minimum  number  of  maintenance  visits  is  specified.  If  the  alternative  is 
deemed  viable  (achieves  goals  within  constraints),  it  can  be  further  modified  or  another 
alternative  can  be  selected  as  a  new  starting  point. 

After  a  suitable  number  (determined  by  the  team)  of  viable  alternative  redundant 
configurations  have  been  developed,  these  configurations  are  evaluated  and  compared  to 
determine  which  one  best  meets  the  constraints  for  the  lowest  cost.  If  several  alternatives 
have  nearly  the  same  LCC,  other  attributes  and  design  considerations  are  used  in  the 
selection  process  to  determine  the  best  alternative.  The  specialty  team  relies  on  the 
creativity,  experience,  and  expertise  of  team  members  to  address  those  attributes  and 
considerations  affected  by  modifications  but  not  directly  considered  in  the  methodology. 

F.  COMPUTER  SUPPORT 

Before  a  design  session  begins,  the  specifications  for  the  baseline  system  must  be 
entered  into  the  computer  data  base.  This  information  includes,  for  each  possible  element 
in  the  system,  such  things  as  reliability,  repair  times,  and  cost.  Additional  information  is 
also  required  to  compute  the  constraint  and  goal  metrics.  This  information  includes  items 
such  as  service  life,  cost  of  maintenance  manpower,  travel  costs,  and  a  discount  rate  for 
computing  the  present  value  of  the  cost  stream  associated  with  a  series  of  maintenance 
visits  extending  from  initial  operational  capability  throughout  the  service  life  of  the  system. 

The  software  provides  the  team  with  the  capability  to  enter,  display,  and  save 
alternative  redundant  system  configurations  and  to  estimate  the  reliability  of  these  redundant 
systems  under  alternative  maintenance  visit  schedules.  It  also  allows  the  team  to  estimate 
acquisition  costs  and  life  cycle  maintenance  visit  costs  for  systems  with  redundant 
elements. 

A  detailed  description  of  the  software  supporting  the  methodology  and  the 
equations  and  analytical  assumptions  underlying  the  methodology  are  given  in  Appendix  C. 
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IV.  DEMONSTRATION 


i 


A.  OVERVIEW 

On  September  20,  1989,  the  methodology  developed  in  this  project  was 
demonstrated  and  evaluated  at  the  University  of  Maryland.  Representatives  of  AFHRL, 
IDA,  the  University  of  Maryland,  Texas  Instruments,  and  Westinghouse  Electric 
participated  in  the  demonstration  and  evaluation. 

The  agenda  for  the  demonstration  and  evaluation  is  shown  in  Table  IV- 1,  and  the 
people  who  participated  in  the  demonstration  and  evaluation  are  shown  in  Table  TV-2. 


Table  IV-1.  Meeting  Agenda 


Time 

Agenda  Item 

Speaker/Participant 

0930-0945  hours 

Opening  Remarks 

W.  Cralley,  IDA 

0945-1000  hours 

Scenario  for  Methodology 

D.  Dieroif,  IDA 

1000-1015  hours 

Break 

1015-1200  hours 

Theory  behind  Assessment 
Metrics  and  Representation  of 
Baseline  System 

M.  Pecht,  University  of 

Maryland 

1200-1330  hours 

Lunch 

1330-1530  hours 

Alternative  Generation 

All  Participants 

1530-1630  hours 

Discussion 

All  Participants 

1630  hours 

Closing  Remarks 

W.  Cralley,  IDA;  Cpt.  Hill, 

AFHRL 
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Table  IV-2.  Meeting  Participants 


Name 

Affiliation 

Position 

Mr.  Frank  Roth 

Texas  Instruments 

Systems  Engineer 

Mr.  Dino  Fieni 

Westinghouse  Electric 

Reliabiity  Engineer 

Dr.  Michael  Pecht 

University  of  Maryland 

Director,  CALCE  Center 

Mr.  Hugh  Reinhart 

University  of  Maryland 

Graduate  Student 

Ms.  Chu  Zhang 

University  of  Maryland 

Graduate  Student 

Mr.  B.T.  Sawyer 

University  of  Maryland 

Software  Engineer 

Cpt.  Ray  Hill 

AFHRL 

Project  Manager 

Mr.  Wiliam  Crafley 

IDA 

Project  Manager 

Mr.  David  Dierolf 

IDA 

Research  Staff  Member 

Dr.  Karen  Richter 

IDA 

Research  Staff  Member 

B .  DEMONSTRATION  ACTIVITIES 

The  background  of  the  research,  the  conceptual  approach  taken,  the  scenario  for  the 
methodology  development,  and  the  theory,  equations,  and  metrics  underlying  the 
assessment  capability  were  explained  to  the  meeting  participants.  The  material  presented 
follows  the  descriptions  given  in  Chapter  IE  and  Appendix  C  and  will  not  be  repeated  here. 
(Appendix  C  also  contains  a  user's  guide  to  the  CALCE  software  used  in  the 
demonstration.) 

This  section  describes  the  input  data  required  to  exercise  the  software  supporting 
the  methodology  and  the  output  results  provided  by  this  software.  It  also  contains  a 
description  of  the  alternative  generation  process  and  an  example  of  this  process  that 
illustrates  the  activities  during  this  portion  of  the  demonstration. 

1.  Operation  of  the  Software 

A  design  is  entered  into  the  computer  by  specifying  a  hierarchical  description,  often 
called  a  high-level  bill  of  materials.  This  hierarchical  description  identifies  the  lowest  level 
elements  on  which  repair  will  be  conducted.  For  purposes  of  this  project,  repair  is  defined 
as  removal  and  replacement  of  all  elements  of  the  system  that  are  found  to  have  failed  at  the 
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time  of  a  maintenance  visit.  Deferred  maintenance  of  certain  failed  elements  discovered 
during  scheduled  or  unscheduled  maintenance  actions  is  not  considered  in  the  methodology 
developed  in  this  project,  although  it  is  a  valid  maintenance  strategy  that  could  be 
considered  in  actual  maintenance  situations. 

Each  element  of  the  hierarchy  has  a  set  of  associated  attributes,  as  shown  in  Table 
IV-3.  All  attributes,  with  the  exception  of  those  used  for  part  identification,  require 
numerical  values.  Some  of  these  values  are  assigned  by  the  user,  the  remaining  are 
computed  from  other  attributes  and  may  not  be  changed. 

Table  IV-3.  Element  Attributes 


User  Defined 

Calculated 

•  Total  number  of  elements  present  in  the 
system 

•  Total  number  of  elements  required  for 
operation  of  the  system 

•  Duty  cycle 

•  Element  failure  rate 

•  Unit  cost  of  an  element 

•  Repair  time  (time  to  remove  and  replace 
an  element  of  the  system) 

•  Element's  percent  of  the  total  system 
failure  rate 

•  Element  equivalent  failure  rate 

•  Element  equivalent  failure  rate  with  repair 

The  duty  cycle  of  an  element  is  the  ratio  of  the  element's  operating  time  to  the  total 
system  operating  time;  it  is  used  in  calculating  the  reliability  of  the  element.  The  percent  of 
the  total  failure  rate  is  the  failure  rate  of  the  element  divided  by  the  total  system  failure  rate. 
The  equivalent  failure  rate  is  the  failure  rate  that  a  group  of  identical  elements  (including 
some  that  are  redundant)  would  have  if  this  group  were  considered  as  a  single  aggregated 
element  Note  that  even  if  each  element  has  an  exponential  failure  distribution,  the  failure 
distribution  of  a  group  of  such  elements  will  not  be  exponential  if  redundancy  is  present. 
Thus  the  equivalent  failure  rate  is  useful  only  as  a  heuristic  and  is  not  actually  used  in 
calculating  the  total  system  failure  rate. 

Each  design  configuration  has  a  set  of  global  system-level  parameters  associated 
with  it  These  parameters  are  shown  in  Table  IV -4.  Default  values  are  initially  assigned  to 
these  parameters.  Some  global  parameters  can  be  changed  by  the  user,  while  others  are 
calculated  and  may  not  be  changed.  Parameters  that  can  be  edited  include  service  life, 
number  of  maintenance  visits  per  year,  travel  cost  of  a  maintenance  visit,  and  discount  rate 
to  be  applied  for  determining  LCC.  MTBCF,  system  reliability  with  and  without  repair, 
series  failure  rate,  and  series  MTBF  are  computed  from  the  other  parameters. 
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Table  IV -4.  Global  System  Parameters 


User  Defined 

Calculated 

•  Service  life 

•  System  refiabiity  with  repair 

•  Maintenance  visits  per  year 

*  System  refiability  without  repair 

•  Maintenance  labor  rate 

*  System  failure  rate  (failures  per  million  hours) 

•  Travel  cost  for  a  maintenance  visit 

•  Series  failure  rate  (assumes  all  elements, 
even  redundant  ones,  must  be  operational 
for  the  system  to  operate) 

•  Discount  rate  for  computing  present  value  of 
maintenance  visit  cost  streams 

•  MTBF  (for  the  series  system) 

•  MTBCF 

•  MTTR 

•  LCC  indicator 

The  software  supports  the  selection  of  elements  to  make  redundant  by  highlighting 
those  with  the  highest  equivalent  failure  rates.  Two  types  of  redundancy,  passive  (or 
standby)  and  active,  can  be  considered  by  the  team  to  reduce  the  LCC  of  the  baseline 
system. 

2.  Alternative  Generation 

The  starting  point  for  the  demonstration  was  a  baseline  configuration  for  a 
subsystem  of  the  ARSR-4  with  no  redundancies  (a  series  configuration  for  reliability 
estimation  purposes).  Table  IV-5  shows  the  attributes  oi  tne  elements  in  the  baseline 
configuration.  The  global  parameters  for  this  configuration  arc  shown  in  Table  IV-6.  Note 
that  scheduled  maintenance  does  not  improve  the  reliability  of  a  series  configuration  system 
(assuming  exponential  failure  distributions).  Thus,  system  failure  rate  with  repair  is  the 
same  as  without  repair,  and  MTBCF  is  equal  to  MBTF  for  this  configuration. 

In  the  demonstration,  constraining  requirements  were  specified  for  both  minimum 
reliability  for  the  system  in  series  configuration  (MTBF)  and  for  system  reliability 
(MTBCF)  for  the  subsystem  of  the  ARSR-4  being  considered.  The  MTBF  requirement 
was  6,500  hours,  and  the  MTBCF  requirement  was  100,000  hours. 

The  following  procedure  was  followed  during  the  alternative  generation  process: 

•  Add  redundancy  to  a  selected  system  element 

•  Check  to  see  if  the  MTBF  constraint  is  satisfied  (if  not,  no  level  of  scheduled 
maintenance  will  suffice  to  make  the  design  feasible) 


Table  IV-5.  Attributes  of  Elements  In  Baseline  Configuration 


Diagram 

No. 

Description 

Repair 

Time 

(hrs) 

Total 

Units 

Required 

Units 

Unit 

Cost 

($) 

Unit 

Fafl 

Rate 

Series 

Fal 

Rate 

% 

Total 

Fail 

Rate 

SI 

BSj 

Equiv 

Fal 

Rate 

ai 

01 

Pulse 

comparator 

0.8 

1 

1 

2000 

14.770 

14.770 

22.3 

1.00 

14.770 

14.770 

a2 

02 

Doppler  filter 

8.4 

1 

1 

1000 

17.230 

17.230 

26.1 

1.00 

17.230 

17.230 

a3 

03 

Positive  detection 
identifier 

2.0 

1 

1 

1000 

14.190 

14.190 

21.5 

1.00 

14.190 

14.190 

a4 

04 

Computer  false 
alarm  rate  (CFAR) 

1.0 

1 

1 

1000 

13.340 

13.340 

20.2 

1.00 

13.340 

13.340 

a5 

05 

Channel  interface 

2.0 

1 

1 

1000 

6.562 

6.562 

09.9 

1.00 

6.562 

6.562 

Table  IV-6.  Global  Parameters  for  Baseline  Subsystem 


Service  life 

43,850  hours 

Maintenance  visits/year 

0 

System  reliability  with  repair 

0.055126 

System  reliability  without  repair 

0.555126 

Series  failure  rate 

66.09  failures  per  million  hours 

MTBCF 

15,130.4  hou'S 

MTBF  (series) 

15,130.4  hours 

MTTR 

3.21  hours 

LCC  indicator 

6,000  $ 
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•  Determine  the  minimum  number  of  maintenance  visits  per  year  needed  to 
achieve  the  MTBCF  requirement  (or  determine  that  no  number  of  maintenance 
visits  will  suffice,  meaning  the  design  is  infeasible) 

•  Determine  the  LCC  indicator  for  this  configuration 

•  Record  details  of  the  configuration  and  parameter  values  for  reference 

•  Modify  the  configuration  and  repeat  the  preceding  steps. 

During  the  demonstration,  the  alternative  generation  process  was  repeated  several 
times.  Dr.  Pecht  operated  the  computer  for  the  team  during  this  session. 

An  account  of  the  various  configurations  and  the  results  for  each  one  was 
maintained  manually.  A  sample  of  these  configurations  is  presented  in  the  following 
section,  illustrating  the  support  the  CALCE  software  provides. 

3.  Examples  Of  Alternative  Generation 

Table  IV-7  shows  the  baseline  system  with  a  redundant  Doppler  filter  as  the  first 
alternative  configuration.  Table  IV- 8  shows  the  system  parameters  for  this  alternative.  The 
addition  of  the  redundant  component  decreases  the  MTBF  while  increasing  the  MTBCF. 
With  five  scheduled  maintenance  visits  per  year,  the  MTBCF  is  still  far  below  the 
requirement  of  100,000  hours.  Even  with  additional  maintenance  visits,  this  configuration 
is  unable  to  meet  the  MTBCF  requirement 


Table  IV-7.  Baseline  System  with  a  Redundant  Doppler  Filter 


Block 

ID 

Diagram 

No. 

Description 

Total 

Units 

Required 

Units 

Unit 

Fail 

Rate 

Equiv 

Fail 

Rate 

With 

Repair 

ai 

01 

Pulse  comparator 

1 

1 

m 

14.770 

a 2 

02 

Doppler  filter 

2 

1 

3.974 

a3 

03 

Positive  detection  identifier 

1 

1 

warn 

14.190 

a4 

04 

Computer  false  alarm  rate  (CFAR) 

1 

1 

BBS 

33.340 

a5 

05 

Channel  interface 

1 

1 

H 

6.562 

I 
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Table  IV-8.  System  Parameters  for  Alternative  In  Table  IV-7 


Service  life 

43,850  hours 

Maintenance  visits/year 

5.00 

System  reliability  with  repair 

0.1147793 

System  reliability  without  repair 

0.0843560 

Series  failure  rate 

83.32  failures  per  million  hours 

MTBCF 

20,259.30  hours 

MTBF  (series) 

12,001.60  hours 

MTTR 

4.29  hours 

LCC  indicator 

22.472.30  $ 

Initial  parts  cost 

7,000.00  $ 

Total  maintenance  cost 

618.61  $/visft 

Spare  parts  cost 

112.02  $/visit 

Repair  time 

0.13  hours/visit 

Maintenance  person  cost 

50.00  $/visit 

Travel  cost 

500.00  $/visit 

Discount  rate 

0.0  % 

Table  IV-9  shows  the  attributes  for  an  alternative  configuration  with  multiple 
redundancies.  Table  IV-10  shows  the  system  parameters  for  this  alternative.  The  MTBCF 
requirement  of  100,000  hours  is  met,  as  well  as  the  MTBF  requirement  of  6,500  hours. 
The  additional  redundancies  allow  the  number  of  scheduled  maintenance  visits  to  be 
reduced  to  one  every  two  years.  The  value  of  this  reduction  is  shown  bv  the  LCC  indicator 
($15,531),  which  is  less  than  the  LCC  indicator  of  the  first  alternative,  which  did  not  meet 
the  reliability  requirements. 


Table  IV-9.  System  with  Multiple  Redundant  Elements 


Block 

ID 

Description 

Total 

Units 

Required 

Units 

Unit 

Fail 

Rate 

Equiv 

Fail 

Rate 

With 

Repair 

al 

01 

Pulse  comparator 

2 

1 

ess 

3.025 

a2 

02 

Doppler  filter 

3 

1 

1.016 

a3 

03 

Positive  detection  identifier 

2 

1 

IB 

2.815 

a4 

04 

Computer  false  alarm  rate  (CFAR) 

2 

1 

BS9 

2.519 

a5 

05 

Channel  interface 

2 

1 

Ka 

0.676 

Tabl«  IV- 10.  System  Parameters  for  Alternative  In  Table  IV-9 


Service  life 

43,850  hours 

Maintenance  visits/year 

0.5 

System  reliability  with  repair 

0.6691264 

System  reliability  without  repair 

0.3891756 

Series  failure  rate 

149.41  failures  per  million  hours 

MTBCF 

10,160.00  hours 

MTBF  (series) 

6,692.80  hours 

MTTFt 

3.81  hours 

LCC  indicator 

15,531.59  $ 

Initial  parts  cost 

13,000.00  $ 

Total  maintenance  cost 

1,012.18  $/visit 

Spare  parts  cost 

468.97  $/visit 

Repair  time 

0.86  hours/visit 

Maintenance  person  cost 

50.00  $/visit 

Travel  cost 

500.00  $/visit 

Discount  rate 

0.0  % 

C.  DEMONSTRATION  FINDINGS 

Following  the  session,  all  participants  discussed  the  methodology.  Due  to  cost  and 
schedule  constraints,  not  all  issues  could  be  addressed  in  the  implementation  of  the 
methodology.  The  following  sections  describe  the  issues  that  were  addressed  and  the 
major  findings  from  the  demonstration. 

I .  Identifying  Where  to  Add  Redundancy 

While  adding  redundancy  to  the  system  element  with  the  highest  failure  rate  (or 
equivalent  failure  rate  when  scheduled  maintenance  is  being  performed)  seems  most  logical 
for  improving  system  reliability,  this  modification  does  not  always  lead  to  a  better  solution 
in  terms  of  LCC.  Recall  that  increasing  the  level  of  redundancy  increases  both  acquisition 
cost  and  the  cost  of  each  maintenance  visit  (due  to  the  increased  opportunity  for  sub¬ 
elements  to  fail  between  visits).  Whether  the  increased  system  reliability  that  results  from 
adding  such  redundancy  will  allow  the  frequency  of  maintenance  visits  to  be  reduced 
sufficiently  to  offset  these  additional  costs  is  often  not  intuitively  obvious.  More 
economical  improvements  yielding  an  equivalent  improvement  in  system  reliability  may 
possibly  be  obtained  by  adding  redundancies  to  a  less  costly  element 
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In  addition,  an  element  with  a  very  low  failure  rate  may  be  critical  to  the  operation 
of  the  system.  Some  subsystems,  such  as  power  supplies,  are  known  to  be  failure  prone 
and  are  made  redundant  in  systems  such  as  the  ARSR-4.  Other  reasons  for  demanding 
redundancy  in  certain  systems  include  difficulty  of  fault  isolation  when  a  certain  component 
fails  or  an  explicit  desire  by  the  customer  for  redundancy  for  certain  components.  The  level 
of  criticality  of  an  element  is  an  important  factor  in  determining  which  elements  to  make 
redundant  to  ensure  the  system  does  not  fail.  The  methodology  should  provide  for 
mandatory  redundancy  in  certain  subsystems.  For  various  portions  of  the  ARSR-4, 
redundancy  is  impossible  because  of  size,  weight,  or  cost  constraints.  Consideration 
should  be  given  to  providing  for  such  constraints  in  the  software. 

The  functional  relationship  between  improving  reliability  through  added  redundancy 
and  improving  reliability  through  increased  scheduled  maintenance  frequencies  is  complex. 
Identifying  the  optimal  solution  in  terms  of  LCC  appears  to  be  a  very  difficult  analytical 
problem.  While  the  CALCE  software  supporting  the  present  methodology  allows  the 
product  development  team  to  explore  various  options,  it  can  only  provide  general 
indications  as  to  where  to  place  additional  redundancies  to  improve  LCC.  Adding 
redundancy  to  the  system  element  with  the  highest  equivalent  failure  rate,  for  example, 
often  is  a  good  approach,  but  this  approach  is  not  necessarily  the  optimal  approach,  as  was 
noted  in  the  preceding  paragraph. 

Thus,  at  present,  the  team  must  rely  on  the  expertise  of  members  in  determining 
which  element  to  make  redundant  While  an  analytical  solution  to  this  problem  seems 
unlikely,  especially  if  the  entire  radar  system  is  considered,  better  heuristics  could  help 
guide  the  product  development  team  in  selecting  where  to  place  redundancies,  leading  to 
improvements  in  the  resulting  designs  and  a  more  efficient  product  development  process. 
Development  of  such  heuristics  could  be  the  topic  of  future  research  projects. 

2 .  Initiating  and  Managing  Trade  Studies 

Trade  studies  are  usually  the  result  of  a  product  development  team  member’s 
uncovering  a  particular  problem  and  convincing  management  that  such  a  problem  should  be 
addressed.  Trade-off  studies  are  costly  and  time  consuming,  and  only  studies  offering 
significant  product  improvement  should  be  undertaken.  Engineering  experience  and 
judgment  become  critical  factors  in  identifying  which  of  the  many  possible  trade-offs 
should  be  conducted,  given  the  limited  time  available  to  the  team.  Methods  for  identifying 
and  managing  such  efforts  should  be  improved.  As  expanded  capabilities  for  conducting 
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trade-off  analyses  are  added  to  the  software,  deciding  which  options  to  explore  becomes 
increasingly  difficult.  The  number  of  potential  excursions  rapidly  expands,  and  team 
members  may  spend  valuable  time  on  issues  with  limited  payoff  (or  analyze  less  viable 
trade-offs).  A  structured  way  to  make  decisions  requiring  experience  and  judgment  is 
needed  to  best  focus  team  efforts. 

3.  Addressing  Ramifications  of  Increased  Redundancy 

Adding  more  active  redundancy  increases  system  power  requirements.  Since 
power  supplies  are  notoriously  unreliable,  the  possibility  exists  that  increasing  the 
reliability  of  one  part  of  the  system  through  added  redundancy  could  result  in  a  decrease  in 
total  system  reliability  or  an  increase  in  total  system  logistics  support  burden  and  cost 

While  increased  size  and  weight  accruing  from  more  redundancy  may  not  be  of 
considerable  importance  in  a  ground-based  system,  they  must  be  considered  in  avionics. 
In  the  case  of  high-performance  fighter  aircraft,  increases  in  weight  or  space  requirements 
can  require  a  multitude  of  other  design  changes,  which  can  cause  significant  problems. 

Increased  system  complexity  resulting  from  more  redundancy  will  increase  system 
development  costs  in  a  manner  that  is  not  reflected  in  the  acquisition  cost  portion  of  the 
LCC  indicator.  In  particular,  additional  funding  for  design  and  prototype  development  and 
testing  will  likely  be  required. 

Additional  costs  may  also  accrue  from  the  support  equipment  needed  to  handle 
additional  redundancies.  Such  costs  are  related  to  the  need  for  additional  sensing  and 
switching/voting  circuitry,  interconnection  devices,  and  added  demand  for  environmental 
conditioning. 

Additional  failures  may  occur  due  to  support  equipment  needed  to  handle 
redundancies.  Failures  in  sensing  circuits  or  interconnections,  for  example,  are  not 
accounted  for  in  the  current  methodology. 

Increased  difficulties  in  fault  detection  and  isolation  may  result  from  increased 
redundancy.  This  can  lead  to  an  increase  in  false  removals,  resulting  in  increased  logistic 
support  costs  in  terms  of  spares  and  manpower  utilization.  Such  additional  costs  are  not 
handled  in  the  current  methodology;  the  methodology  assumes  100  percent  fault  isolation. 

Any  or  all  of  these  considerations  should  be  addressed  through  additional  research 
to  improve  the  accuracy  of  the  metrics  now  present  in  the  current  methodology. 
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4.  Assessing  Life  Cycle  Cost 

Aside  from  costs  resulting  from  increased  redundancy  noted  in  the  preceding 
paragraphs,  procedures  used  to  estimate  the  other  costs  in  the  methodology  could  also  be 
more  realistic.  The  approach  taken  in  the  methodology  involving  use  of  an  LCC  indicator 
and  separate  estimates  for  parts  and  maintenance  costs  was  viewed  as  useful  and 
appropriate  by  the  demonstration  participants  from  industry.  The  individual  components  of 
this  indicator,  however,  could  be  more  accurate. 

For  example,  the  methodology  now  uses  total  parts  cost  to  represent  the  acquisition 
cost  of  the  system;  however,  the  cost  of  the  parts  is  only  a  small  portion  of  the  total 
acquisition  cost.  The  large  expenditures  for  engineering  man-hours  and  overhead  are 
ignored.  Thus,  one  enhancement  to  the  methodology  could  be  developing  a  more  realistic 
acquisition  cost  indicator. 

The  support  cost  indicator,  the  maintenance  visit  cost,  could  be  modified  to  more 
accurately  reflect  the  support  costs  by  considering  items  such  as  levels  of  maintenance 
(with  considerations  of,  for  example,  the  relative  costs  of  built-in-test  versus  external  test 
equipment). 

While  more  realistic  cost  indicators  are  desirable,  it  was  strongly  recommended  by 
industry  representatives  at  the  demonstration  that  a  full  LCC  model  not  be  incorporated  into 
the  analysis.  The  analysis  results  of  such  models  are  not  viewed  credible  by  many,  and 
industry  acceptance  of  the  validity  of  such  models  was  not  considered  sufficient  to  justify 
their  use  in  the  methodology. 

5 .  Recording  Team  Activities 

An  audit  trail  of  the  various  alternatives  considered  by  the  product  development 
team  during  the  trade-off  process  should  be  provided.  A  way  to  save  alternative 
configurations  and  their  associated  analysis  results  is  needed.  Maintaining  the  history  of  a 
small  subsystem  would  not  necessarily  require  significant  computing  resources.  If  the 
entire  radar  is  modeled,  maintaining  an  audit  trail  could  require  significant  amounts  of 
storage  and  entail  significant  information  management  problems. 

6.  Assessing  the  Entire  Radar 

While  the  methodology  demonstrates  the  concept  of  performing  trade-offs  of 
redundancy  versus  maintenance  visits,  for  such  trade-offs  to  be  realistic,  the  entire  radar 
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system  must  be  modeled.  This  need  raises  issues  related  to  increasing  the  computer 
support  capabilities  to  handle  the  level  of  detail  required.  To  allow  addressing  issues  such 
as  assessing  the  relative  benefits  of  changing  the  quality  level  of  a  certain  part,  which  may 
appear  500  times  in  a  number  of  separate  subsystems,  additional  computer  support 
capabilities  are  needed.  These  capabilities  are  also  needed  because  the  builder  of  the  radar 
warrants  the  entire  system  and  is  interested  in  the  reliability  and  maintenance  cost  of  the 
total  system,  not  just  a  small  subsystem  as  was  used  in  the  demonstration. 

D.  LIMITATIONS  OF  THE  DEMONSTRATION 

The  overall  results  of  the  demonstration  suggest  that  the  methodology  represents  a 
useful  initial  step  towards  supporting  concurrent  engineering  teams.  Two  caveats  must  be 
noted.  First,  the  demonstration  was  limited  to  one  day.  Considerations  such  as  the  validity 
of  the  equations  used  in  the  methodology  could  not  be  assessed  during  the  demonstration. 
Second,  the  participants  in  the  demonstration,  unlike  the  members  of  a  concurrent 
engineering  team,  had  nothing  at  stake  in  the  outcome  of  this  meeting.  In  industry,  the 
participants  in  the  product  development  team  meeting  would  represent  the  views  of  certain 
constituencies.  These  views  could  lead  to  conflicts  that  would  have  to  be  resolved. 
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V.  FINDINGS  AND  RECOMMENDATIONS 


This  project  has  successfully  demonstrated  how  the  conceptual  approach  of  DFA 
can  be  applied  to  design  for  supportability.  A  number  of  findings  and  many  research 
opportunities  were  identified  during  this  project.  These  findings  have  been  grouped  into 
three  categories  and  are  presented  in  the  following  sections. 

A.  ORGANIZING  AND  MANAGING  TEAMS 

Having  a  core  product  development  team  that  charters  specialty  teams  as  needed 
was  the  IDA  research  team's  vision  of  how  product  development  teams  could  be  organized. 
The  organizational  issues  involved  with  creating  and  managing  concurrent  engineering 
teams,  and  in  particular,  the  activities  of  multiple  teams,  warrants  a  substantial  research 
effort.  A  core  team,  like  the  one  envisioned  for  this  project,  could  coordinate  the  work  of 
the  other  teams,  each  of  which  would  be  investigating  certain  problems  and  conducting 
trade  studies.  However,  one  team  could  conduct  a  study  indicating  that  a  certain  course  of 
action  should  be  followed  to  realize  certain  benefits,  yet  this  action  may  create  problems  for 
another  team  that  is  trying  to  achieve  other  goals.  Such  conflicts  must  be  resolved. 

The  most  common  way  of  resolving  such  conflicts  is  through  design  review  boards 
(which  often  meet  after  design  decisions  are  made)  and  ultimately,  by  autocratic  decisions 
made  by  engineering  management.  This  approach  often  leads  to  failure  to  identify  and 
resolve  major  conflicts  until  a  stage  in  the  design  process  in  which  design  changes  are  very 
expensive.  A  better  way  is  needed. 

During  the  demonstration  of  the  methodology  developed  for  this  project,  the  group 
interactions  were  completely  unstructured.  However,  structured  group  problem  solving 
methodologies  have  been  shown  to  make  group  problem  solving  more  efficient. 
Identifying  promising  structured  group  problem  solving  methodologies  for  concurrent 
engineering  is  another  area  for  research. 

This  project  has  shown  that  government  requirements,  such  as  specifying  the 
number  of  maintenance  visits,  can  place  unnecessary  constraints  on  a  product  development 
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team.  This  type  of  limitation  could  result  in  products  with  LCC  higher  than  necessary.  An 
approach  to  product  acquisition  in  which  the  requirements  are  jointly  developed  by  a  team 
consisting  of  both  government  and  industry  personnel  would  result  in  requirements  that  do 
not  unnecessarily  restrict  the  design  freedom  of  the  product  development  team.  The 
research  team  did  not  consider  the  legal  or  political  issues  associated  with  using  such  an 
approach  to  acquisition.  These  issues  would  have  to  be  addressed  before  such  an  approach 
to  acquisition  could  be  implemented. 

B .  COMPUTER-AIDED  GROUP  PROBLEM  SOLVING 

The  proper  role  of  the  computer  in  support  of  group  problem  solving  is  an  area  of 
growing  research.  Approaches  range  from  the  group  sharing  a  single  computer  during  the 
meeting  (as  was  done  in  this  project)  to  providing  a  separate  computer  for  each  person  at 
the  meeting.  Other  areas  of  research  are  concerned  with  supporting  the  group  when  they 
are  working  in  a  distributed  environment 

This  project  has  demonstrated  that  software  originally  designed  for  a  single-user 
can  be  used  in  a  group  setting.  Contrary  to  claims  made  by  some  researchers,  specific 
group-oriented  software  is  not  necessarily  required.  The  use  of  other  single-user  software 
in  group  settings  should  be  explored. 

How  the  computer  support  for  the  team  is  developed  is  an  open  issue.  One 
approach  is  to  let  the  product  development  team  build  its  own  computer  models  using 
spreadsheets  or  similar  software  shells.  One  advantage  of  models  that  are  actually  built  by 
the  team  is  that  the  team  members  will  be  confident  of  the  model's  accuracy  because  the 
team  verified  the  validity  of  the  approach  used  in  such  models. 

C.  DESIGN  FOR  MAINTAINABILITY 

The  final  area  that  requires  additional  research  is  developing  design  for 
maintainability  methodologies  and  tools.  Significant  gaps  exist  in  the  field  of  design  for 
maintainability.  The  review  of  the  research  literature  found  a  lack  of  consensus  in  the 
research  community  on  the  definition  of  maintainability  and  how  to  design  for 
maintainability.  Many  of  the  industry  maintainability  specialists  interviewed  during  this 
study  defined  designing  for  maintainability  as  calculating  the  Military  Handbook  472 
attributes  of  a  design,  such  as  mean  time  to  repair  (MTTR). 

The  available  measurements  of  maintainability  have  not  kept  pace  with  advancing 
technology.  For  example,  the  techniques  proposed  in  MIL-HDBK  472  do  not  properly 
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handle  designs  in  which  high  reliability  is  achieved  through  use  of  redundancy  with  repair. 
In  such  situations,  scheduled  maintenance  is  the  key  element~not  corrective  maintenance, 
which  is  ihe  only  item  addressed  in  the  handbook. 

D.  FUTURE  DIRECTIONS 

The  methodology  developed  during  the  course  of  this  project  only  begins  to  address 
the  many  considerations  relating  to  incorporation  of  supportability  into  the  product 
development  process.  Much  remains  to  be  done.  However,  the  results  of  this  project, 
which  was  limited  in  its  scope  and  handing,  clearly  indicate  that  there  is  great  potential  for 
improving  development  processes  through  use  of  relatively  simple  approaches  to  aid 
product  development  teams.  The  conceptual  approach  of  Boothroyd  and  Dewhurst,  which 
has  been  proven  successful  in  improving  the  ease  of  assembly  of  designs,  and  has  been 
applied  to  limited  aspects  of  supportability  in  this  project,  can  also  be  applied  to  many  other 
issues  that  must  be  addressed  if  the  goals  of  improved  quality,  reduced  cost,  and  shortened 
development  lead  time  are  to  be  attained.  Moreover,  such  applications  need  not  be  costly  to 
develop.  The  relative  benefits  from  taking  such  an  approach  on  major  weapon  system 
acquisition  programs  are  likely  to  be  great 
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MAINTAINABILITY 


A.  BACKGROUND 

An  extensive  literature  review  of  supportability  issues  in  engineering  product 
development  began  early  in  this  research  and  continued  throughout  the  effort  The  focus 
shifted  from  general  supportability  issues  to  consideration  of  maintainability;  this  appendix 
discusses  the  results  of  the  focused  review  and  survey.  Discussions  with  maintainability 
experts  and  review  of  the  literature  revealed  a  lack  of  consensus  on  the  definition  of 
maintainability  [Ref.  A-l].  The  literature  search  also  indicated  that  many  evaluation 
checklists  and  guidelines  for  design  for  maintainability  exist;  however,  since  no  generally 
accepted  definition  of  maintainability  exists,  no  published  guidelines  were  found  to  be 
universally  applicable  [Ref.  A-2],  Furthermore,  the  relationship  between  design  decisions 
and  maintenance  and  logistics  policy  decisions  seems  poorly  understood. 

B .  HISTORY  OF  MAINTAINABILITY  AS  A  DISCIPLINE 

Maintainability  has  existed  as  an  engineering  discipline  since  the  early  1950s.  At 
that  time,  the  maintainability  of  a  design  was  considered,  but  maintainability  engineers 
would  receive  the  design  after  the  main  design  group  was  finished  with  it.  At  this  stage, 
their  ability  to  influence  a  design  was  limited;  only  minor  improvements  in  the 
maintainability  of  the  product  could  be  made.  Maintainability  engineers  had  no  influence  in 
the  major  design  decisions,  where  the  opportunities  for  product  improvement  were 
greatest.  In  recent  years,  with  the  advent  of  complex  systems  requiring  highly  skilled 
technicians,  the  importance  of  considering  maintenance  during  all  stages  of  the  design 
phase  has  been  widely  recognized. 

As  with  most  engineering  disciplines,  the  need  for  the  study  of  maintainability 
preceded  its  inception  as  a  design  discipline.  The  most  significant  factor  driving  the 
original  development  of  the  discipline  was  the  invention  of  complex  electronics  systems 
built  with  vacuum  tubes.  The  poor  reliability  of  these  systems  necessitated  their  constant 
maintenance  and  repair.  Many  of  these  early  systems  had  mean  times  between  failure 
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(MTBF)  of  20  to  100  hours.  The  components  of  these  systems  were  hand  soldered  in 
place,  with  litde  consideration  given  to  the  e«se  of  replacement  Built-in  diagnostics  or 
testability  woe  almost  unheard  of,  and  the  use  of  designed  test  points  was  not  extensive. 

The  natural  delay  between  the  development  of  theory  and  its  practical  application 
was  partly  to  blame  for  the  delay  in  the  use  of  maintainability  theories;  however,  the 
emphasis  on  acquisition  costs  instead  of  the  more  substantial  utilization  costs  probably  was 
a  more  significant  factor.  The  widespread  application  of  maintainability  techniques  can  be 
traced  to  the  original  issue  of  Military  Standards  470,  471,  and  472  in  1966.  These 
standards  set  maintainability  program  requirements  and  demonstration  and  prediction 
techniques  to  be  used  in  developing  military  systems. 

Since  then,  the  development  of  the  transistor  and  the  integrated  circuit  have  spurred 
major  changes  in  the  field.  Individual  components  are  no  longer  isolated  and  replaced 
when  a  fault  occurs— entire  boards  and  assemblies  are  replaced.  This  modularity  has 
changed  the  emphasis  in  maintainability  from  replacement  methods  to  diagnostics  and 
testability.  The  improvement  in  the  function  of  electronics,  especially  with  the  introduction 
of  the  first  microprocessors  in  1971,  has  allowed  part  of  their  power  output  to  be  dedicated 
to  fault  detecaon  and  isolation.  Automatic  fault  detection  and  isolation  has  simplified  the 
task  of  the  repair  technician. 

The  defense  industry  has  come  to  realize  the  importance  of  maintainability 
considerations.  An  Air  Force  R&M  2000  Initiative  guideline  specifies  that  each  new 
generation  of  a  particular  type  of  system  should  double  the  reliability  and  require  half  the 
maintenance  of  the  preceding  generation  system.  A  recommended  goal  is  the  isolation  of 
failures  down  to  the  smallest  field  replaceable  unit  (FRU)  during  operation  without  the  use 
of  special  tools.  The  acquisition  portion  of  life  cycle  cost  (LCC),  rather  than  the  support 
portion,  is  still  emphasized  in  defense  procurement.  More  research  is  needed  to  improve 
current  techniques  for  design  for  maintainability  and  encourage  their  increased  use 
throughout  a  variety  of  practical  applications. 

C.  DEFINITIONS  OF  MAINTAINABILITY 

The  literature  survey  revealed  that  many  definitions  of  maintainability  exist  in  the 
engineering  community.  A  sampling  of  these  definitions  follow. 

MIL-STD-1388-1A,  Logistics  Support  Analyses 

Maintainability  is  the  measure  of  the  ability  of  an  item  to  be  retained  in  or 

restored  to  a  specified  condition  when  maintenance  is  performed  by 
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personnel  having  specified  skill  levels,  using  prescribed  procedures  and 
resources  at  each  prescribed  level  of  maintenance  and  repair. 

Reliability  Analysis  Center,  RADC-GAFB,  Reliability  Design  Handbook 
(also  MIL-STD-778  ) 

Maintainability  is  a  characteristic  of  design  and  installation  which  is 
expressed  as  the  probability  that  an  item  will  be  retained  in  or  restored  to  a 
specified  condition  within  a  given  period  of  time,  when  the  maintenance  is 
performed  in  accordance  with  prescribed  procedures  and  resources. 

MIL-STD-1472C  Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

Design  for  Maintainability  involves  design  considerations  directed  toward 
achieving  those  combined  characteristics  of  equipment  and  facilities  which 
will  enable  the  accomplishment  of  necessary  maintenance  quickly,  safely, 
accurately,  and  effectively  with  minimum  requirements  for  personnel, 
skills,  special  tools,  and  cost. 

Jones,  J.  V.,  Engineering  Design 

The  probability  that  a  failed  item  can  be  repaired  in  a  specified  amount  of 
time  using  a  specified  set  of  resources  is  called  maintainability.  Note  that 
this  is  a  statistical  prediction,  which  means  that,  like  reliability, 
maintainability  can  be  greatly  influenced  by  variables  such  as  availability  of 
resources  and  environmental  conditions  where  maintenance  is  performed. 

Blanchard,  B.  S.,  and  W.  J.  Fabrycky,  Systems  Engineering  and  Analysis 

Maintainability  is  an  inherent  design  characteristic  of  a  system  or  product  It 
pertains  to  the  ease,  accuracy,  safety,  and  economy  in  the  performance  of 
maintenance  actions.  Systems  engineers  must  be  concerned  with  the  design 
and  development  of  a  system  that  can  be  maintained  in  the  least  amount  of 
time,  at  the  least  cost  and  with  minimum  expenditure  of  support  resources 
(e.g.,  personnel,  materials,  facilities,  test  equipment)  without  adversely 
affecting  the  mission  of  the  system.  Maintainability  is  the  ability  of  an  item 
to  be  maintained,  whereas  maintenance  constitutes  a  series  of  actions  to  be 
taken  to  restore  or  retain  an  item  in  an  effective  operational  state. 
Maintainability  is  a  design  parameter.  Maintenance  is  a  result  of  design. 

Priest,  J.  W.,  Engineering  Design  for  Producibility  and  Reliability 

Maintainability  is  the  design  discipline  concerned  with  the  ability  of  the 
product  to  be  satisfactorily  maintained  throughout  its  intended  useful  life 
span  with  minimum  expenditures  of  money  and  effort.  The  purpose  of 
maintainability  is  to  design  products  so  that  they  may  be  easily  maintained 
and  kept  in  serviceable  condition.  To  accomplish  this  goal  the  system 
should  be  easily  and  quickly  maintained  by 

•  Technicians  with  minimum  skill  levels 

•  The  minimal  number  of  special  tools,  support  equipment,  and  technical 
documentation 

•  Requiring  minimum  scheduled  or  preventive  maintenance 

•  Developing  a  system  for  easy  maintenance  reduces  the  number  of 
maintenance  hours,  skill  level  requirements,  equipment  requirements, 
and  storage  space  requirements. 
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While  all  of  the  definitions  are  similar,  significant  differences  do  exist. 
Maintainability  is  defined  as  a  measure,  an  inherent  characteristic  of  a  system,  and  a  design 
discipline.  From  these  definitions,  what  is  included  in  maintainability  is  not  clear-for 
example,  preventive  maintenance  (PM)  is  included  in  most,  but  not  all,  of  the  definitions. 
Those  definitions  that  define  maintainability  as  a  statistical  measure  cannot  include  many 
less  quantifiable  issues,  such  as  safety.  As  a  design  discipline,  maintainability  is  concerned 
with  cost  effectively  maximizing  operational  availability  by  minimizing  maintenance  times 
and  frequency. 

D.  WORKING  DEFINITION  OF  MAINTAINABILITY 

For  the  purposes  of  this  project,  maintainability  is  defined  as  an  inherent  design 
characteristic  of  a  system  that  pertains  to  the  ease,  accuracy,  and  cost  of  maintaining  the 
system.  The  two  primary  objectives  of  design  for  maintainability  are  to  maximize 
operational  readiness  and  to  minimize  LCC.  Operational  readiness  is  a  measure  of  how 
often  or  how  long  a  system  is  capable  of  successfully  completing  its  mission.  LCC 
includes  all  resources  (personnel,  materials,  facilities,  and  test  equipment)  required  to 
acquire  and  operate  the  system  based  on  assumed  longevity  measured  in  years.  Secondary 
goals  include  improved  mobility  and  simplified  subsystem  upgrade. 

E.  TYPES  AND  COST  OF  MAINTENANCE 

To  maximize  operational  readiness,  system  downtime  between  fully  mission- 
capable  states  must  be  minimized,  while  the  probability  that  nothing  will  fail  during  the 
mission  must  be  maximized.  To  do  this,  PM  and  corrective  maintenance  (CM)  may  be 
considered. 

1.  Preventive  Maintenance 

PM  is  used  to  keep  the  system  in  an  operational  or  available  state  by  preventing 
system  failures  from  occurring.  PM  includes  servicing,  failure  inspection  and  correction, 
recalibration  and  tuning,  and  the  repair  of  parts  that  have  failed  without  causing  system 
failure.  PM  is  typically  scheduled  in  terms  of  the  specified  maintenance  tasks  and  the 
frequency  of  the  maintenance  visits.  Proper  scheduling  of  PM  requires  timely,  accurate 
information  on  the  trends  and  status  of  components  that  are  failing  or  will  fail  due  to  aging. 
PM  results  in  a  reduction  in  the  lifetime  operating  costs  of  complex  systems.  Systems  with 


PM  exhibit  quasi-constant  failure  rates.  A  significant  number  of  operational  failures 
indicate  that  the  time  between  PM  actions  is  too  long. 

One  form  of  PM,  reliability  centered  maintenance  (RCM),  is  required  by  DoD 
Directive  4151.16;  RCM  was  first  used  in  the  commercial  aviation  industry.  Its  purpose  is 
"to  identify  the  essential  preventive  maintenance  tasks  required  to  retain  the  safety  and 
reliability  inherent  in  system  design."  [Ref.  A-3]  This  method  emphasizes  identifying  the 
functions  with  poor  reliability  rather  than  the  individual  parts  or  assemblies.  A  PM  plan 
that  will  improve  this  functional  reliability  is  then  selected.  If  the  plan  improves  reliability 
and  is  cost  effective,  it  is  adopted.  The  process  includes 

•  Identifying  functions  (not  parts)  with  the  worst  reliability  and  the  worst  failure 
modes 

•  Selecting  a  preventive  maintenance  plan  for  this  function 

•  Determining  the  applicability  of  the  plan-whether  it  reduces  the  failure  rate 

•  Determining  the  effectiveness  of  the  plan— whether  it  is  economical. 

To  maximize  the  effectiveness  and  minimize  the  cost  of  PM,  the  time-to-failure 
distributions  and  the  hazard-rate  trends  of  the  maintained  system  and  its  associated  parts 
must  be  known.  For  example,  if  a  part  in  a  series  system  (1  out  of  N:  fail)  has  an 
increasing  hazard  rate,  then  properly  scheduled  preventive  maintenance  will  improve  the 
reliability  of  the  system.  If  a  part  has  a  decreasing  hazard  rate,  any  replacement  of  the  pan 
will  increase  the  probability  of  failure.  If  the  hazard  rate  is  constant,  as  is  often  considered 
the  case  for  electronic  devices,  then  replacement  will  not  affect  the  reliability.  In  fact,  such 
maintenance  actions  are  likely  to  induce  (real  or  reported)  failures.  If  the  system  is 
composed  of  redundant  parts,  scheduled  maintenance  can  be  used  to  improve  the  system 
reliability,  even  if  the  parts  have  constant  or  decreasing  hazard  rates. 

2 .  Corrective  Maintenance 

CM  includes  repair  and  replacement  activities  that  return  the  system  from  a  failed 
state  to  an  operating  or  available  state.  The  frequency  of  CM  depends  on  the  system 
reliability  and  is  not  scheduled.  CM  actions  can  include  fault  detection  and  isolation, 
disassembly,  interchange,  reassembly  alignment,  and  checkout  Minimizing  the  time 
required  for  corrective  maintenance  actions  and  maximizing  the  probability  of  successful 
completion  of  those  actions  are  key  objectives. 


A-5 


3 .  Cost  of  Maintenance 


The  cost  of  maintenance  is  determined  by  the  frequency  of  maintenance,  both 
preventive  and  corrective,  and  the  cost  of  the  logistics  support  required  to  perform  the 
maintenance  actions.  Maintenance  manpower  and  costs  are  related  to  the  frequency  and 
difficulty  of  maintenance  actions.  Logistics  support  costs  are  driven  by  the  total  costs  to 
remove,  replace,  transport,  and  repair  components  at  all  levels  of  maintenance.  The 
logistics  resources  include  personnel,  training,  spare  parts,  test  equipment,  facilities,  and 
data. 

With  modem  weapons  systems,  the  ratio  of  design  to  production  to  operation  costs 
can  average  approximately  1:5:15.  This  ratio  indicates  that  the  largest  improvements  in 
LCC  can  be  obtained  by  decreasing  the  cost  of  operation.  The  greatest  effect  design  for 
maintainability  can  have  on  LCC  is  reducing  the  system  requirements  for  skilled 
maintained.  The  time  required  to  perform  maintenance  actions  and  the  complexity  of  the 
maintenance  actions  will  influence  both  the  number  of  maintained  required  and  their 
training  needs.  Good  design  for  maintainability  techniques  can  decrease  the  number  and 
training  of  the  technicians  needed  to  keep  a  system  running  and  decrease  the  logistics 
requirements  of  a  system,  thus  decreasing  the  LCC  and  improving  the  mobility  of  the 
system. 

F .  THE  ROLE  OF  MAINTAINABILITY  IN  SYSTEM  EFFECTIVENESS 

System  effectiveness,  as  illustrated  in  Figure  A-l,  is  determined  by  a  number  of 
factod  [Ref.  A-3--A-5].  Maintainability,  reliability,  logistics  support,  and  maintenance 
concepts  all  affect  hardware  availability  and  dependability.  Figure  A-l  also  shows  other 
design-related  and  policy-related  decisions  that  affect  reliability  and  maintainability. 
Although  the  designer  could  have  many  options  in  designing  for  availability  or 
dependability,  initial  requirements  specifications  limit  these  options.  One  weakness  in 
product  acquisition  today  is  a  poor  undedtanding  of  the  relationship  between  policy  and 
design  decisions. 

In  Design  for  Maintainability;  What  the  Government  Standards  Do  and  Don't  Say, 

Captain  Donald  Loose,  Air  Force  Human  Resources  Laboratory,  uses  a  figure  (reproduced 

here  as  Figure  A-2)  to  represent  the  paths  of  influence  between  design  for  maintainability 

and  the  system  level  trade-offs  of  LCC  and  operational  readiness  [Ref.  A-2].  The  lines  of 

influence  are  marked  with  current  models  used  for  making  the  calculations  required  in  the 

trade-offs.  The  lines  with  adjacent  question  marks  represent  the  links  that  are  poorly 
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Figure  A-1.  System  Effectiveness  [Ref.  A-5] 
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Figure  A-2.  The  Role  of  Maintainability  in  Systems  Engineering  [Ref.  A-2] 

understood  in  new  design  approaches.  Maintainability  design  will  also  influence 
operational  readiness  through  provisioning  requirements,  support  equipment  requirements, 
and  maintenance  planning. 

G.  FUNDAMENTALS  OF  DESIGN  FOR  MAINTAINABILITY 

The  goal  of  design  for  maintainability  is  to  incorporate  features  into  the  design  that 
improve  the  maintained  abilities  to  assess  and  isolate  faults  and  will  reduce  the  time  to 
repair,  both  preparation  time  and  active  maintenance  time.  Preparation  includes  accessing 
the  proper  maintenance  personnel,  travel,  and  tool  and  equipment  collection.  Active 
maintenance  includes  reading  documentation,  locating  and  correcting  the  problems,  and 
documenting  the  results.  In  addition  to  design-related  repair  times,  logistics  delay  time 
(such  as  waiting  for  spares  once  the  active  maintenance  activity  has  started)  is  also  a  large 
driver  of  mean  time  to  repair.  Policy  issues  such  as  spares  budgets  and  number  of  levels  of 
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maintenance  significantly  affect  the  mean  time  to  repair.  The  total  systems  engineering 
process  for  a  weapon  system  must  consider  design  and  policy  issues  simultaneously  if  life 
cycle  cost  is  to  be  minimized. 

1.  Issues  to  be  Considered  in  Designing  for  Maintainability 

To  be  effective,  designing  for  maintainability  must  include  consideration  of  various 
issues.  For  example,  the  number  of  potential  maintenance  actions  must  be  minimized,  and 
those  remaining  must  be  simplified  (by  lessening  the  number  and  skill  level  of  personnel 
required  and  lessening  the  number  of  special  tools  required).  The  status  of  the  system  must 
be  made  readily  available  through  diagnostics  and  test,  and  considerations  must  be  given  to 
existing  resources,  including  the  manpower,  the  skill  level  of  the  personnel,  and  the 
training  available.  Improved  technology  line  replaceable  unit  (LRU)  replacement  should  be 
permitted  to  provide  for  potential  system  improvements  and  safety  of  the  maintenance 
personnel  must  be  made  a  paramount  design  consideration. 

The  amount  of  maintenance  is  minimized  by  minimizing  the  use  of  parts  requiring 
maintenance  and  improving  the  access  to  these  parts.  Use  of  self-lubricating  and  self¬ 
calibrating  parts  are  two  of  the  techniques  used  to  decrease  maintenance.  Using  snaps 
instead  of  screws  for  covers  and  ensuring  that  no  assemblies  must  be  removed  to  access  a 
maintenance  point  (one  deep  maintenance)  can  decrease  the  time  necessary  for  required 
maintenance.  Modular  systems  with  high  quality  built-in-test  capabilities  can  speed  repair 
actions  significantly.  Ensuring  that  the  assemblies  with  the  worst  reliability  are  the  most 
accessible  can  also  help  to  reduce  repair  times. 

2.  Maintainability  Design  Guidelines 

Various  sources  of  design  for  maintainability  guidelines,  rules,  and  questions  were 
consulted  in  an  attempt  to  derive  a  concise  set  of  generic  design  for  maintainability 
guidelines.  Military  standards  and  handbooks,  checklists,  and  guidelines  used  by 
government,  industry,  and  academia  were  analyzed  for  general  applicability  [Ref.  A-6-- 
A-10]. 

During  the  course  of  the  research,  a  number  of  strawman  sets  of  generic  guidelines 
were  developed  based  on  the  source  material;  however,  the  lists  were  found  to  be 
contradictory  and  controversial  to  some  extent.  The  reason  for  this  disparity  was  given  at 
the  1989  International  Conference  on  Engineering  Design  by  A.  L.  van  der  Mooren  [Ref. 
A-ll). 


It  would  be  very  useful  if  a  set  of  recommendations  could  be  given,  which, 
when  applied  to  any  design,  straight  on  led  to  a  [maintenance  centered]  MC- 
object  But  on  second  thoughts  this  idea  doesn't  seem  feasible.  Even  if 
suggestions  are  not  contradictory  among  themselves,  their  material 
realization  may  lead  to  incompatibility;  more  inspection  holes  in  a  vessel 
e.g.,  may  promote  the  maintainability,  but  reduce  die  reliability.  Thus  only 
conditional  recommendations  can  be  made  and  the  designer  should  in  each 
separate  case  decide  whether  and  how  to  apply  them,  considering  technical 
and  economic  consequences. 

The  research  team  therefore  concluded  that  in  the  case  of  design  for  maintainability, 
unlike  design  for  assembly,  no  concise  set  of  universal  basic  guidelines  could  be  developed 
to  give  to  the  product  development  team.  The  least  objectionable  set  found  by  the  research 
team  appears  to  be  those  given  by  van  der  Mooren  as  the  "ten  commandments"  to  be 
generally  applied  to  enhance  an  object's  overall  maintenance  behavior 

1 .  Keep  the  construction  simple. 

2 .  Use  standardized  components. 

3 .  Take  care  of  good  accessibility. 

4 .  Take  care  of  good  replaceability . 

5 .  Apply  modular  construction. 

6 .  Neutralize  human  errors. 

7 .  Neutralize  developing  damage. 

8 .  Make  the  condition  accessible. 

9 .  Aim  for  self-help. 

10.  Provide  a  maintenance  manual. 

While  these  guidelines  seem  reasonable,  they  are  general  and  may  be  of  little  help  when 
designing  a  specific  system. 

The  following  list  of  guidelines  is  included  to  provide  some  notion  of  the  types  and 
nature  of  the  guidelines  available  in  the  literature.  Such  guidelines  must,  however,  be 
tailored  to  the  specific  problem  being  addressed.  Not  all  of  these  guidelines  will  be 
appropriate  for  all  design  problems. 

•  Minimize  maintenance  downtime  by  using 

-  Maintenance-free  design 

-  Standard,  proven,  and  modular  design  and  parts 

-  Simple,  reliable,  and  durable  design  and  parts 

-  Fail-safe  features  to  reduce  failure  consequences 


-  Worst-case  design  techniques  and  tolerances. 

•  Minimize  maintenance  downtime  by  designing  for  effective 

-  Prediction  or  detection  of  malfunction  or  degradation 

-  Failure  localization  to  the  affected  product  level 

-  Isolation  to  a  replaceable  or  repairable  module  or  part 

-  Correction  by  replacement,  adjustment,  or  repair 

-  Verification  of  correction  and  serviceability 

-  Identification  of  parts,  test  points,  and  connections 

-  Calibration,  adjustment,  servicing,  and  testing. 

•  Minimize  maintenance  costs  by  designing  products  that  minimize 

-  Hazards  to  personnel  and  equipment 

-  Special  tools  required  for  maintenance 

-  Requirements  for  depot  or  contractor  maintenance 

-  Consumption  rates  and  costs  of  spares  and  materials 

-  Personnel  skills. 

•  Minimize  the  complexity  of  maintenance  by  designing  for 

-  Compatibility  among  system  equipment  and  facilities 

-  Standardization  of  design,  parts,  and  nomenclature 

-  Interchangeability  of  like  parts,  materials,  and  spares 

•  Minimum  maintenance  tools,  accessories,  and  equipment 

-  Adequate  accessibility,  work  space,  and  work  clearances. 

•  Minimize  the  maintenance  personnel  requirements  by  designing  for 

-  Logical  and  sequential  function  and  task  allocations 

-  Easy  handling,  mobility,  transportability,  and  storability 

-  Minimum  numbers  of  personnel  and  maintenance  specialities 

-  Simple  and  valid  maintenance  procedures  and  instructions. 

•  Minimize  maintenance  error  by  designing  to  reduce 

-  Likelihood  of  undetected  failure  or  degradation 

-  Maintenance  waste,  oversight,  misuse,  or  abuse 

-  Dangerous,  dirty,  awkward,  or  tedious  repair  tasks 

-  Ambiguity  in  maintenance  labeling  or  coding. 

•  Minimize  the  frequency  of  tool  failure  by 

-  Providing  accessibility,  adequate  work  space,  and  clearance 

-  Ensuring  installation  loads  do  not  exceed  tool  stress  limits. 
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3.  Quantitative  Metrics  for  Maintainability 

In  addition  to  guidelines,  a  product  development  team  needs  some  way  of 
quantifying  the  relative  merits  of  alternative  designs  in  terms  of  maintainability.  The 
following  metrics  have  been  commonly  used  for  this  purpose. 

•  Mean  time  to  repair  (MTTR) 

•  Maximum  time  to  repair 

•  Mean  time  to  restore  system  (MTTRS) 

•  Mean  time  to  restore  function  (MTTRF) 

•  Direct  man-hours  per  maintenance  action  (DMH/MA) 

•  Total  parts  cost  per  removal  (at  all  levels  of  repair) 

•  Probability  (proportion)  of  faults  detected 

•  Proportion  of  faults  isolatable 

•  Level  of  isolation  in  bill  of  material  hierarchy 

•  False  alarm  rates 

•  Maintenance  man-hours/flight  hours/operating  hours. 

These  metrics  can  be  used  in  trade  studies  if  the  information  needed  in  the 
calculations  can  be  acquired.  For  a  metric  such  as  MTTR,  necessary  information  includes 
identification  of  specific  maintenance  tasks  to  be  performed  for  the  system  and  prediction  of 
the  time  required  to  perform  these  tasks.  The  governing  document  for  maintainability 
programs  in  the  Department  of  Defense,  MIL-STD  470A  {Department  of  Defense 
Maintainability  Program  for  Systems  and  Equipment),  provides  general  maintainability  task 
descriptions.  This  standard  is  useful  in  classifying  the  types  of  tasks  that  a  maintainability 
program  could  consider,  although  tailoring  of  the  tasks  to  the  specific  program  is  required. 
The  DoD  governing  document  for  maintainability  calculation  and  prediction  is  Military 
Handbook  472. 

As  in  the  case  of  design  guidelines  for  maintainability,  choice  of  an  appropriate 
metric  (or  metrics)  for  maintainability  depends  on  the  specific  product  development 
problem  being  addressed.  The  product  dt  dopment  team,  as  part  of  the  planning  of  the 
product  development  process,  must  decide  how  they  will  address  maintainability  in 
conducting  trade-offs. 
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H.  CONCLUSIONS 

No  universal  consensus  exists  for  the  definition  of  maintainability.  Maintainability 
is  interpreted  in  various  ways  by  different  specialists  in  the  product  development  process. 
The  systems  engineer,  the  logistics  specialist,  and  the  hardware  engineer  all  have  different 
views.  The  variety  of  guidelines,  some  of  which  are  contradictory,  that  have  been 
published  concerning  maintainability  reflect  the  lack  of  consensus  on  the  definition  of 
maintainability. 
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Engineering  Design,  Volume  /,  22-25  August  1989,  Harrogate  International 
Centre,  pp.  1227-1238. 
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MAINTAINABILITY  ANNOTATED  BIBLIOGRAPHY 


Abstract  of  Lessons  Learned,  Fifth  Edition,  Air  Force  Lessons  Learned  Program, 
Directorate  of  Systems  Support,  Air  Force  Acquisition  Logistics  Center  (AFALC),  Wright- 
Patterson  AFB,  OH,  1  March  1988. 

The  AFALC  was  originally  formed  with  a  primary  mission  of  bridging  the 
gap  between  the  acquisition  and  logistics  communities  to  improve  reliability 
and  supportability  of  new  weapons  systems  coming  into  the  Air  Force 
inventory  while  lowering  the  cost  of  ownership  for  those  systems.  One 
valuable  method  of  meeting  this  goal  is  the  compilation  of  past  program 
management  experiences  in  the  form  of  lessons  learned.  The  Deputy  tor 
Integrated  Logistics,  AFALC/LS,  has  been  assigned  the  responsibility  of 
implementing  the  Lessons  Learned  Program.  The  Directorate  of  Systems 
Support,  AFALC/LSL,  has  the  task  of  gathering,  assigning,  storing  and 
disseminating  lessons  within  the  acquisition  and  logistics  communities. 

Basically,  the  data  base  contains  two  types  of  lessons  learned:  management 
and  technical.  Management  Lessons  address  program  decisions  and  actions 
in  such  areas  as  program  control,  budget/financial  control,  contracting 
techniques,  support  planning,  configuration  management,  maintenance 
concepts  and  data  management.  Technical  Lessons  relate  to  systems, 
equipment  and  components,  including  hardware,  software,  support 
equipment,  or  the  design  factors  that  influence  the  performance  of  the 
system  or  equipment 

Acquisition  Management,  Repair  Level  Analysis  (RLA)  Procedures,  AFLC/AFSC 
Pamphlet  800-4,  Department  of  the  Air  Force,  Headquarters  Air  Force  Logistics 
Command,  Wright-Patterson  AFB,  OH  and  Headquarters  Air  Force  Systems  Command, 
Andrews  AFB,  DC,  25  November  1983. 

This  pamphlet  tells  how  to  formulate  and  implement  repair  level  analysis 
(RLA),  formerly  optimum  repair  level  analysis  (ORLA)  on  new  systems, 
equipment  and  major  modification  programs.  This  is  a  guide  for  Air  Force 
Logistics  Command  (AFLC)  and  Air  Force  Systems  Command  (AFSC) 
organizations  to  use  in  acquiring  new  systems  and  equipment.  It  gives 
contractors  and  prospective  contractors  an  economic  basis  on  which  to 
recommend  levels  of  repair  or  discard-at-failure  for  system  components. 

'Hie  intent  of  this  pamphlet  is  to  improve  logistics  cost  effectiveness  and  the 
operational  capability  of  future  systems.  It  does  this  by  ensuring  the 
methods  for  developing  valid  maintenance  plans  become  an  integral  part  of 
engineering  development 
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Acquisition  Management,  USAF  R&M  2000  Process ,  AFLC/AFSC  Pamphlet  800-7, 
Department  of  the  Air  Force,  Headquarters,  U.S.  Air  Force,  Washington,  DC,  1  January 
1989. 


This  pamphlet  describes  how  to  increase  combat  capability  while  saving 
resources  through  good  reliability  and  maintainability  (R&M)  practices. 

The  pamphlet  describes  Air  Force  goals  for  R&M  and  a  set  of  guiding 
principles  and  practical  building  blocks  which  should  be  considered 
'preferred"  practices  for  identifying  operational  R&M  requirements; 
motivating  defense  contractors;  and  developing,  producing,  and  maintaining 
Air  Force  systems.  Successful  program  managers  repeatedly  cite  these 
methods  as  the  ones  they  use  to  meet  or  exceed  customers'  R&M 
expectations  while  satisfying  other  program  objectives.  The  pamphlet  is 
written  in  nontechnical  language  and  is  designed  for  a  variety  of  audiences 
at  all  organizational  levels,  both  in  the  Air  Force  and  the  defense  industry. 

AFP  800-7  complements  Air  Force  Regulation  800-2. 

Adams,  W.E.,  Lockheed-Georgia  Company,  "Avionic  Flight  Control  Subsystem  Design 
and  Integration  in  the  C-5  Airplane,"  Aircraft  Design  Integration  and  Optimization,  Volume 
1,  Advisory  Group  for  Aerospace  Research  and  Development  (AGARD)  Conference 
Proceedings  No.  147,  NATO,  43rd  Meeting  of  the  Flight  Mechanics  Panel  of  AGARD 
held  at  Scuola  di  Guerra  Aerea,  Florence,  Italy,  1-4  October  1973,  published  June  1974. 

The  preliminary  design  process  had  significant  influence  on  the  C-5  avionic 
flight  control  system  development,  production,  and  operational  cost.  The 
design  decisions  made  during  the  preliminary  design  phase  relative  to  the 
stability  augmentation  systems  illustrate  the  extent  of  the  impact  on  the 
design,  test,  manufacture,  and  installation  of  the  avionic  systems.  These 
decisions  lie  mainly  in  the  areas  of  mission  success  capability,  airplane 
safety,  reliability,  survivability,  and  human  factor  characteristics  and,  for 
the  illustrative  stability  augmentation  systems,  the  aircraft's  handling 
qualities.  The  design  processes,  including  the  subsystem  integration  with 
the  airframe  and  with  other  functional  subsystems,  influenced  the  cost  of  the 
C-5  program.  Experience  gained  from  this  program  may  lead  to 
improvements  in  preliminary  design  decision  making  procedures. 

Advanced  Concepts  for  Avionics/Weapon  System  Design,  Development  and  Integration, 
Advisory  Group  for  Aerospace  Research  and  Development,  AGARD  Conference 
Proceedings  No.  343,  NATO,  Copies  of  papers  presented  at  the  Avionics  Panel  45th 
Symposium  held  at  Ottawa,  Canada,  18-22  April  1983. 

In  order  to  realize  the  performance  in  the  development  of  modem  military 
aircraft,  full  advantage  is  taken  of  the  rapid  advances  in  the  computer  and 
electronic  technologies.  Thus,  as  each  new  aircraft  design  depends 
increasingly  on  avionics,  the  overall  system  becomes  more  versatile,  but 
also  more  complex. 

Modem  weapon  systems  are  being  structured  with  more  interdependency 
among  subsystems.  However,  potential  maximum  benefits  of  subsystem 
and  weapon  development  integration  have  not  yet  been  realized. 

In  order  to  realize  the  benefits  of  advanced  integration  concepts  and  maintain 
compatible  timescales  throughout  the  subsystems  development  and  test 
phase,  intelligent  integrated  design  concepts  and  proper  coordination  of  the 
development  program  are  essential. 
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New  design  and  development  strategies  should  be  considered  in  order  to 
achieve  the  technical  and  performance  benefits  expected  of  highly  advanced 
and  integrated  avionics/weapon  systems  in  an  economical  and  timely 
manner.  The  applicable  design  and  development  concepts  being  considered 
as  appropriate  for  presentation  and  discussion  in  this  meeting  are  as  follows: 

-  Initiate  design  in  terms  of  overall  system  to  satisfy  operational 
requirement 

-  Conduct  parallel  design  and  development  activities  in  all  relevant 
disciplines 

-  Retention  of  design  and  application  flexibility  and  growth  in  subsystems 
by  means  of  appropriate  data  processing  and  subsystem 
inter/intracommunications  structure 

-  Planning  of  logistic  support  elements  including  reliability, 
maintainability  and  supportability  as  well  as  life  cycle  cost 
considerations 

-  Comprehensive  integrated  ground  testing  prior  to  airborne  evaluation  of 
the  weapon  systems 

-  Comprehensive  integrated  ground  testing  prior  to  airborne  evaluation  of 
the  weapon  systems 

The  objective  of  this  meeting  was  to  exchange  information  and  ideas  among 
the  various  disciplines  involved  in  weapon  system  design  to  the  benefit  of 
integrated  system  developments  for  future  defense  programs.  The  meeting 
contributed  to  a  mutual  understanding  of  the  tasks  of  all  specialists  involved 
in  the  realization  of  integrated  weapon  systems. 

Air  Force  Lessons  Learned  Bulletin,  Reliability  and  Maintainability,  Directorate  of  Systems 
Support,  Air  Force  Acquisition  Logistics  Center  (AFALC),  Wright-Patterson  AFB,  OH, 
23  February  1989. 

Reliability  and  maintainability  are  key  factors  that  influence  system  design, 
system  effectiveness,  logistics  support  requirements  and  life  cycle  costs 
(LCC). 

Reliability  and  maintainability  are  different,  but  complementary,  engineering 
disciplines.  Reliability  is  concerned  with  the  ability  of  a  system  to  operate 
for  a  specified  period  of  time,  in  a  specified  manner,  without  failure  or 
serious  degradation.  Maintainability  is  concerned  with  how  quickly  the 
system  can  be  restored  to  working  order  once  it  has  failed.  Together,  the 
R&M  features  of  a  system  help  determine  the  system's  effectiveness  in 
doing  its  assigned  mission. 

There  are  two  clearly  distinct  kinds  of  reliability-mission  reliability  and 
logistics  reliability.  Mission  reliability  is  the  probability  that  a  system  will 
successfully  complete  its  mission.  Logistics  reliability  is  the  probability  that 
a  system  will  operate  as  planned  under  defined  operational  and  support 
concepts,  using  specified  logistics  resources  (spares  and  maintenance 
manpower).  These  two  kinds  of  reliability  often  conflict.  It  is  the  job  of  the 
R&M  manager  specifically,  and  the  program  manager  in  general,  to  address 
and  resolve  this  conflict  within  the  constraints  of  the  total  program. 

Maintainability  is  a  part  of  systems  engineering  and  program  management, 
and  represents  a  large  part  of  total  systems  resources  and  costs.  It  must  be 
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considered  in  terms  of  the  system  life-cycle  with  respect  to  program  and 
system  planning,  system  tradeoffs,  and  LCC. 

The  lessons  learned  contained  in  this  bulletin  are  collected  to  help  die  R&M 
manager  carry  out  an  effective  R&M  program  and  to  encourage  dialogue 
between  engineering  operations  and  support  personnel  so  that  answers  to 
questions  and  solutions  to  problems  can  be  found. 

Other  bulletins  containing  information  that  could  aid  the  R&M  effort  are 
Accessibility,  Automatic  Test  Equipment,  Corrosion,  Fault  Isolation  and 
Failure  Verification,  Life  Cycle  Cost,  Logistics  Support  Analysis, 
Maintenance  Planning,  Quality  Assurance,  Survivability,  Test  and 
Evaluation,  and  Training  and  Training  Support.  This  bulletin  should  be 
used  in  concert  with  these  other  bulletins. 

Air  Force  Lessons  Learned  Bulletin,  Maintenance  Planning ,  Directorate  of  Systems 
Support,  Air  Force  Acquisition  Logistics  Center  (AFALC),  Wright-Patterson  AFB,  OH, 
23  February  1989. 

Maintenance  Planning  establishes  the  requirements  for  both  on-  and  off- 
equipment  maintenance,  to  be  performed  during  the  life  of  the  system  or 
equipment 

Maintenance  planning  defines  the  actions  and  support  necessary  to  ensure 
that  the  system  or  equipment  attains  specified  operational  capability,  sets  the 
specific  criteria  for  repair  times,  repair  levels,  testability,  logistics  reliability 
and  maintainability  characteristics,  support  equipment  requirements, 
manpower  skills,  and  facility  requirements.  Additionally,  maintenance 
planning  states  the  extent  and  use  of  interim  contractor  support  (ICS). 

This  bulletin  contains  a  collection  of  lessons  learned,  documented  from 
existing  programs.  Contained  are  examples  of  both  successful  and  less 
successful  applications  of  the  maintenance  planning  concept  Potential 
users  may  have  constraints  not  considered  in  the  appropriate  action 
statement,  however,  the  conditions  or  results  presented  in  the  lessons 
should  be  considered  in  decisions  involving  similar  questions  so  that  the 
same  type  of  problems  may  be  avoided. 

1985  Joint  AFSCIAFLC  Reliability  and  Maintainability  Workshop  Proceedings,  Volume 
II,  Air  Force  Systems  Command/ Air  Force  Logistics  Command,  13-15  November  1985, 
Wright-Patterson  AFB,  OH. 

This  workshop  was  designed  to  provide  a  forum  for  Air  Force  personnel  to 
discuss  how  to  successfully  implement  reliability  and  maintainability.  The 
goal  of  the  workshop  was  to  increase  the  manager's  awareness  of  the 
opportunities  available  for  substantial  R&M  improvement.  This  volume 
contains  presentations  on  R&M  success  stories,  contractual  procedures, 
how  Air  Force  organizations  are  successfully  implementing  R&M,  R&M 
tasks,  and  the  use  of  proven  R&M  tools  and  techniques. 

Anderson,  R.T.,  Reliability  Design  Handbook,  ITT  Research  Institute,  under  contract  to 
Rome  Air  Development  Center,  Griffiss  Air  Force  Base,  NY,  Catalog  No.  RDH-376, 
March  1976. 

This  Reliability  Design  Handbook  is  intended  to  serve  as  a  tool  for 
designers  of  military  equipment  and,  in  particular,  for  designers  of 
equipment  items  that  would  typically  make  up  avionics  systems.  The 
handbook  provides  guidelines  for  use  by  design  engineers  to  assure  the 
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achievement  of  a  reliable  end  product  From  the  standpoint  of  design,  it  is 
consistent  with,  and  extends,  basic  concepts  and  reliability  improvement 
techniques  described  in  MIL-HDBK-217B.  Specifically,  the  handbook 
provides  design  information,  factors,  and  parameters,  and  other  engineering 
data  affecting  reliability.  In  addition,  the  handbook  describes  the  approach 
to  reliable  design,  includes  theoretical  and  cost  considerations  and  describes 
methods  covering  such  considerations  as  part  control,  derating, 
environmental,  resistance,  redundancy  and  design  evaluation. 

Berger,  Robert  L.,  AFSC,  Aeronautical  Systems  Division,  "A  Systems  Approach- 

Minimizing  Avionics  Life  Cycle  Cost,"  Thirteenth  Intersociety  Conference  on 

Environmental  Systems,  11-13  July  1983,  San  Francisco,  CA.,  831107,  SAE  Technical 

Paper  Series. 

This  paper  introduces  a  new  concept  in  air-airframe  environmental  control 
system  (ECS)  and  avionics  (airborne  electronic  equipment)  integration 
which  provides  a  method  of  optimizing  system  reliability  while  minimizing 
system  life  cycle  cost  (LCQ.  This  concept  is  being  introduced  under  a  new 
program  sponsored  by  the  Aeronautical  Systems  Division  at  Wright- 
Patterson  AFB  for  defining  equipment  thermal  and  reliability  requirements 
and  optimizing  cooling  capacity  and  its  allocation  to  equipments.  The 
proposed  systems  approach  provides  increased  effectiveness  in  achieving 
reliability  throughout  the  acquisition  process.  This  is  accomplished  by 
putting  product  assurance  in  the  hands  of  the  design  engineers  rather  than 
relying  totally  on  the  test  or  quality  control  engineer.  The  concept  addresses 
specific  tasks  that  need  to  be  accomplished  at  both  the  system  and 
subsystem  levels  to  ensure  the  integrity  of  the  total  program.  The  concept  is 
applicable  to  any  electronic  equipment,  military  or  commercial. 

New  concepts  include  allocating  cooling  at  the  system  level  based  on 
minimizing  overall  system  LCC  and  requiring  that  the  thermal  design  of 
electronic  equipment  be  based  on  minimizing  the  LCC  of  the  equipment 
rather  than  just  meeting  a  reliability  goal. 

Bhagat,  Wilbur,  Wright-Patterson  AFB,  "R&M  Through  Avionics/Electronics  Integrity 

Program,"  IEEE,  1989  Proceedings,  Annual  Reliability  and  Maintainability  Symposium, 

Atlanta,  GA,  24-26  January,  pp  216-219. 

This  paper  addresses  the  importance  of  designing  reliability  and 
maintainability  (R&M)  in  the  electronic  equipment  in  the  early  stages  of  its 
development  and  describes  a  new  approach  called  "Avionics/Electronics 
Integrity  Program"  (AVIP)  which  emphasizes  early  attention  to  design 
criteria  and  analysis,  and  dictates  a  process  which  strikes  a  balance  between 
analysis  and  test.  This  paper  outlines  some  of  the  problems  and  limitations 
that  have  been  observed  using  the  traditional  reliability  approach  (MIL-STD- 
785  process)  and  discusses  how  the  AVIP  approach  will  overcome  these 
problems  and  limitations.  AVIP  retains  and  incorporates  the  proven  and 
useful  elements  of  the  traditional  reliability  approach,  such  as  Failure 
Modes,  Effects  and  Criticality  Analysis  (FMECA),  Failure  Reporting, 
Analysis  and  Corrective  Action  System  (FRACAS),  and  Environmental 
Stress  Screening  (ESS).  This  paper  is  intended  to  provide  the  R&M, 
design  and  management  communities  with  a  basic  understanding  of,  and  an 
insight  into,  the  process  of  achieving  electronics  R&M  through  the  AVIP 
approach. 


B-5 


Blanchard,  Benjamin  S.  and  Wolter  J.  Fabrycky,  Virginia  Polytechnic  Institute,  Systems 
Engineering  and  Analysis ,  Prentice-Hall  International  Series  in  Industrial  and  Systems 
Engineering,  WJ.  Fabrycky  and  J.H.  Mize,  Editors,  1981. 

Boehm,  Manfred,  "Maintainability,  an  ILS  Effort  to  Manipulate  LCC,"  Design  for  Tactical 
Avionics  Maintainability ,  Advisory  Group  for  Aerospace  Research  and  Development, 
AGARD  Conference  Proceedings  No.  361,  NATO,  Copies  of  papers  presented  at  the 
Avionics  Panel  47th  Symposium  held  at  Quartier  Reine  Elisabeth,  Brussels,  Belgium,  7-10 
May  1984. 

Maintainability  is  a  word,  which  is  in  everybody's  mind  today,  but  which  at 
the  same  time  implies  different  understanding  and  selective  interpretation. 

This  is  caused  by  the  variety  of  individual  personnel  activities  and 
responsibilities  with  their  specific  motives  and  objectives.  There  is  a  wide 
scale  of  interests  from  the  sole  operational  motive  to  personal  motives  at  the 
customer  side  as  well  as  at  the  manufacturer  side,  everyone  wanting  to 
protect  mainly  their  own  interests. 

In  order  to  balance  all  these  difference  considerations  there  is  only  one 
solution~dialogue-a  cooperative  dialogue  between  all  partners  involved  to 
follow  the  objective  as  to  minimize  the  cost  factor  for  the  system/equipment 
utilization  phase. 

The  dialogue  has  to  be  initialized  already  in  the  early  system  definition  phase 
because  the  foundation  of  the  maintainability  with  all  its  positive  and 
negative  consequences  has  already  been  performed  in  that  early  life  cycle 
phase. 

Failures  in  this  phase  may  have  catastrophical  effects  onto  the  LCC-factor  of 
utilization.  Therefore,  special  attention  shall  be  given  to  the  development 
phase  with  its  relevant  elements  and  considerations. 

The  divergence  of  interests  and  interdependences  of  maintainability  and 
operational  performance  parameters  will  be  demonstrated  with  the  example 
of  the  development  of  a  Nose  Radar  System  concept  for  a  military  fighter 
aircraft. 

Boothroyd,  Geoffrey  and  Peter  Dewhurst,  Product  Design  for  Assembly,  Boothroyd 
Dewhurst,  Inc.,  Wakefield,  RI.,  January  1987. 

The  Product  Design  for  Assembly  technique  described  in  this  handbook  is 
concerned  with  reducing  the  cost  of  a  product  through  simplification  of  its 
design.  The  best  way  to  achieve  this  cost  reduction  is  first  to  reduce  the 
number  of  individual  parts  that  must  be  assembled  and  then  to  ensure  that 
the  remaining  parts  are  easy  to  manufacture  and  assemble.  The  analysis 
technique  is  systematic  in  its  approach  and  is  a  formalized  step-by-step 
process. 

Assembly  cost  is  largely  determined  at  the  design  stage.  The  designer 
should  be  aware  of  the  nature  of  assembly  processes  and  should  always 
have  sound  reasons  for  requiring  separate  parts  (and  hence  higher  assembly 
costs)  rather  than  combining  several  parts  into  one  manufactured  item.  The 
designer  should  always  keep  in  mind  that  each  combination  of  two  parts 
into  one  will  eliminate  at  least  one  operation  in  manual  assembly  or  an  entire 
section  of  an  automatic  assembly  machine. 

It  is  important  to  have  a  measure  of  how  efficient  the  design  is  in  terms  of 
assembly.  This  handbook  shows  how  to  quantify  this  factor. 
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Buche,  J.  and  I.  Cohen,  Grumman  Aerospace  Corp.,  "Translating  Supportability 
Requirements  into  Design  Reality,"  presented  at  the  AIAA/AHS/AS  EE  Aircraft  Systems, 
Design  and  Technology  Meeting,  Dayton  OH,  20-22  Oct  86,  /.  Aircraft,  Vol.  24,  No.  8, 
pp.  490-494,  A87-50333,  Technical  Information  Services,  American  Institute  of 
Aeronautics  and  Astronautics,  New  York,  NY. 

This  paper  explores  some  of  the  principal  issues  in  the  integration  of 
supportability  into  the  design  process.  Roles  of  the  contractor's  design, 
supportability,  and  management  specialists  and  their  government 
counterparts  are  discussed  as  they  relate  to  logistics  influence  in  design. 
Methods  and  processes  by  which  weapon  system  logistics  and  readiness 
requirements  are  established,  assessed,  allocated  to  system  elements,  and 
translated  into  specific  design  features  are  described.  Tradeoff 
consideration,  an  approach  to  effective  tradeoff  criteria,  and  the  progress  of 
supportability  issues  through  the  program  phases  are  identified,  with 
particular  emphasis  on  the  necessity  for  developing  and  maintaining  an 
♦tffective  audit  trail 

Carter,  John,  Marsland-Carter  Company  Limited,  "Maintenance  Management- 
Computerised  Systems  Come  of  Age,"  Computer-Aided  Engineering  Journal,  December 
1985,  pp.  182185. 

Maintenance  management  has  always  required  the  manipulation  of  large 
amounts  of  data,  and  the  development  of  more  cost-effective  processing, 
storage  and  database  systems  has  brought  the  use  of  computers  to  the  fore 
in  this  area.  This  article  considers  the  evolution  of  specialized  equipment 
maintenance,  the  capabilities  of  today's  computer-aided  maintenance 
systems  and  the  emerging  expert  systems  technology. 

Correale,  Herman,  "Supportability  by  Design  Using  CALS,"  Proceedings  of  the  1987 
IEEE  Annual  Reliability  and  Maintainability  Symposium,  pp.  192-195,  A87-46713, 
Technical  Information  Service,  American  Institute  of  Aeronautics  and  Astronautics,  New 
York,  NY. 

This  paper  addresses  current  developments  and  unsolved  issues  related  to 
the  growing  emphasis  on  Computer  Aided  Logistic  Support  (CALS)  as  an 
industry  and  government  strategy  for  increasing  supportability,  reducing 
costs  and  increasing  war  fighting  capabilities  of  weapon  systems.  It 
emphasizes  the  increasing  involvement  by  all  parties  in  achieving  the  stated 
Department  of  Defense  (DoD)  CALS  goals,  and  pushing  digital  information 
technologies  to  new  levels  of  application. 

Czajkiewicz,  Zbigniew  J.,  Wichita  State  University,  "Optimization  of  the  Maintenance 
Process,"  Simulation,  March  1985,  pp.  137-141. 

A  comprehensive  preventive  maintenance  program  minimizes  equipment 
breakdowns  and  cuts  operating  costs,  which  in  turn  improves  productivity. 

A  mathematical  definition  of  the  maintenance  process  and  criteria  for  its 
optimization  is  presented  in  two  stages:  (1)  structural  optimization  of  a 
maintenance  process  by  selecting  an  appropriate  repair  strategy  and  (2) 
parametrical  optimization  consisting  of  choosing  optimal  (based  on  assumed 
criterion)  times  and  scopes  of  repair  actions.  General  classification  of  the 
repair  strategies,  their  characteristics  and  results  of  simulation  experiments 
are  presented. 
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Definitions  of  Terms  for  Reliability  and  Maintainability ,  Military  Standard,  MIL-STD- 
721C,  Department  of  Defense,  12  June  1981. 

This  Standard  defines  words  and  toms  most  commonly  used  that  are 
associated  with  Reliability  and  Maintainability  (R&M).  It  is  intended  to  be 
used  as  a  common  base  for  R&M  definitions  and  to  reduce  the  possibility  of 
conflicts,  duplications,  and  incorrect  interpretations  either  expressed  or 
implied  elsewhere  in  documentation.  The  definitions  address  die  intent  and 
policy  of  DoD  Directive  5000.40.  Statistical  and  mathematical  terms  that 
have  gained  wide  acceptance  are  not  defined  in  this  Standard  since  they  are 
included  in  other  documents. 

Denney,  Robert  O.,  Mike  J.  Partridge,  and  Roger  B.  Williams,  Boeing  Aerospace  Co., 
"Integrated  Testing  and  Maintenance  Technologies,"  Final  Technical  Report  for  Period  25 
September  1981  -  15  September  1983,  AF  Wright  Aeronautical  Laboratories,  Wright- 
Patterson  AFB,  OH,  AFWAL-TR-83-1183,  December  1983,  Defense  Technical 
Information  Center,  Alexandria,  VA. 

Maintenance  of  weapon  systems  is  becoming  an  increasingly  important 
consideration  in  weapon  system  development  because  the  cost  of 
maintenance  is  a  significant  portion  of  the  life  cycle  cost  of  the  system.  The 
objective  of  the  Integrated  Testing  and  Maintenance  Technologies  effort  is  to 
define  requirements  for  an  onboard  test  system  for  the  avionic  suite  planned 
for  tactical  fighters  in  the  1990's.  Problems  with  current  onboard  test 
systems  were  analyzed  to  determine  where  improvements  could  be  made. 

In  addition,  the  anticipated  avionic  architecture  and  mission  of  the  1990's 
were  evaluated  to  determine  the  impact  on  maintenance  capability. 
Requirements  for  the  Integrated  Testing  and  Maintenance  System  were 
developed  and  documented  in  a  system  specification.  Identified 
improvements  over  current  systems  include  better  filtering  of  intermittent 
failure  reports,  better  isolation  of  intermittent  failures  through  the  use  of 
recorded  data,  more  extensive  use  of  system-level  tests  of  mission 
operational  data  and  a  man-machine  interface  providing  more  information  to 
the  maintenance  technician.  In  addition,  artificial  intelligence  applications 
were  evaluated  to  determine  where  they  might  be  effectively  applied  to  ITM. 

A  design  concept  for  a  fault  classification  expert  system  was  developed. 

Design  for  Tactical  Avionics  Maintainability,  Advisory  Group  for  Aerospace  Research  and 
Development,  AGARD  Conference  Proceedings  No.  361,  NATO,  Copies  of  papers 
presented  at  the  Avionics  Panel  47th  Symposium  held  at  Quartier  Reine  Elisabeth, 
Brussels,  Belgium,  7-10  May  1984. 

The  inherent  logical  make-up  of  digital  systems  makes  possible  the 
opportunity  for  s  large  improvement  in  the  maintainability  cost  of  avionics. 
Limited  success  in  the  use  of  Built-in-Self-Test/Built-in-Test  (BIST/BIT) 
for  fault  detection  and  location  has  discouraged  users.  The  promised  high 
percentage  detection  capability  has  resulted  in  an  increased  in-service 
delivered  performance,  but  not  has  high  as  predicted,  and  false  alarms  have 
increased.  Past  and  current  digital  systems  have  had  BIST/BIT  as  an 
added-on  feature  when  it  should  have  been  incorporated  into  the  original 
design. 

Testability  must  become  a  basic  system  design  objective.  However,  only 
recently  did  adequate  tools  and  advanced  technology  become  available  upon 
which  to  base  imaginative  new  approaches  to  BIST/BIT.  These  new  ideas 
are  expected  to  produce  accurate  and  efficient  test  programs  and  techniques. 
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With  the  rapid  increase  in  the  use  of  embedded  computers  in  the  avionics 
system  and  equipment,  maintenance  of  the  avionics  software  has  not  been 
designed  with  low  life-cycle  maintenance  as  an  objective.  Development 
concepts,  methods  and  tools  aimed  at  a  well-structured,  testable  process  will 
overcome  past  deficiencies. 

The  objective  of  this  symposium  was  to  bring  forward  for  Avionics  Panel 
review  and  discussion  the  development  methods  and  techniques  on  both  the 
hardware  and  software  sides  of  the  maintainability  issue. 

Dickman,  Thomas  J.  and  Major  Thomas  M.  Roberts,  The  Analysis  Sciences  Corporation, 
"Modular  Avionics  System  Architecture  Decision  Support  System,"  Proceedings  of  the 
IEEE  National  Aerospace  and  Electronics  Conference,  Dayton,  OR,  23-27  May  1988, 
Vol.  4  (A88-50926  22-01),  New  York,  IEEE,  pp.  1549-1552. 

This  study  develops  a  methodology  for  evaluating  modular  avionics 
applications  in  terms  of  life  cycle  cost  and  system  effectiveness.  The 
methodology  is  to  be  used  to  compare  alternative  modular  architecture 
strategies  as  well  as  conventional  strategies  for  introducing  avionics  into 
new  or  existing  weapon  systems.  The  study  is  one  of  a  series  of  tasks 
commissioned  by  ASD/AX  as  part  of  the  pre-FSD  investigation  of  modular 
avionics  alternatives.  The  process  described  herein  is  intended  to  be  a 
flexible  means  of  evaluating  postulated  alternatives  for  Air  Force  wide 
implementation  of  modular  avionics.  The  analysis  is  expected  to  be 
performed  using  data  normally  available  during  the  conceptual  phase  of  a 
development  program.  Avionics  has  had  a  relatively  small  impact  on 
weapon  system  effectiveness  but  that  impact  is  increasing.  Functions 
performed  by  avionics  have  been  limited  to  navigation,  communications, 
and  some  portion  of  fire  control.  The  role  of  avionics,  however,  has 
steadily  increased  with  each  new  generation  of  aircraft.  Today  avionics  is 
an  integral  part  of  fire  control,  flight  control,  engine  control,  and  defensive 
countermeasures  in  addition  to  navigation  and  communication  systems. 
Modular  avionics  alternatives  offer  potential  improvements  in  capability  by 
allowing  common  tasks  to  be  performed  by  identical  hardware  and  software 
elements.  Commonality  of  avionics  elements  within  weapon  systems  and 
among  weapon  systems  may  reduce  both  development  cost  and 
development  risk.  Reliable  common  avionics  elements  offer  the  potential  of 
reducing  the  avionics  support  burden.  The  impact  on  the  overall  weapon 
system  effectiveness  has  not  yet  been  determined. 

Fleming,  Randall,  Jill  V.  Josselyn  (Systems  Control  Technology,  Inc.),  and  Paul  Boyle 
(Northrop  Aircraft  Division),  "Integrated  Design  of  Modular  Avionics  for  Performance  and 
Supportability,"  Proceedings  of  the  IEEE  National  Aerospace  and  Electronics  Conference, 
Dayton,  OR,  18-22  May  1987,  Vol.  4  (A88-34026  130-01),  New  York,  IEEE,  Inc.,  pp. 
1296-1303. 

Modem  weapon  systems  currently  being  developed  are  relying  more  and 
more  upon  higher  levels  of  avionics  system  integration  in  order  to  meet 
projected  weapon  system  requirements.  Traditional  driving  factors  in 
weapons  system  design  relating  to  performance  are  being  mitigated  by  cost 
and  manpower  constraints  related  to  life  cycle  costs  and  logistic  support. 
Current  techniques  for  developing  LCC  and  ILS  requirements  may 
seriously  impact  the  performance  of  a  weapon  system  if  they  are  not 
accounted  for  early  in  the  design  process. 
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This  paper  presents  a  case  study  of  a  generic  complex  modular  avionics 
system  during  system  and  subsystem  design  phases.  The  case  study 
demonstrates  setup  and  application  of  an  integrated  performance  and 
supportability  analysis  methodology.  Although  the  methodology  was 
originally  set  up  for  supportability  design  and  analysis  only,  die  capability 
and  structure  for  integration  of  performance  issues  developed  as  the  result 
of  evaluating  the  impact  of  weapons  systems  constraints  on  the  system 
design  and  support  issues.  A  quantitative  system  mission  and  functional- 
driver  link  between  supportability  requirements  and  specific  design  issues 
was  established  early-on.  This  enabled  numerous  design 
tradeoffs/improvements  for  supportability  throughout  the  program.  The 
methodology  and  analysis  provided  a  program-directed  focus  breaking 
across  traditional  organizational  and  communications  barriers  in  avionics 
design  and  analysis. 

Gardner,  Capt.  Thurman  D.,  "An  Examination  of  Operational  Availability  in  Life  Cycle 
Cost  Models,"  A  Thesis,  LSSR  57-83,  Air  Force  Institute  of  Technology,  September 
1983,  Wright-Patterson  AFB,  OH.,  Defense  Technical  Information  Service,  Alexandria, 
VA. 


The  research  objective  was  to  show  weapon  system  availability  as  a  critical 
factor  that  must  be  evaluated  as  part  of  the  first  Life  Cycle  Cost  (LCC) 
estimate.  A  three-part  approach  was  used  to  substantiate  the  objective. 

First,  the  acquisition  directives  were  examined  to  determine  if  availability 
was  an  objective.  Secondly,  some  common  LCC  models  were  analyzed  for 
purposes  of  adapting  applicable  models  to  calculate  availability.  Lastly,  the 
output  of  an  adapted  model  was  used  in  a  tradeoff  analysis  of  similar 
avionics  packages  to  determine  if  the  added  availability  information  was 
useful.  The  results  of  the  approach  showed  that  the  guidance  provided  a 
poor  representation  of  availability.  The  guidance  did  show  availability 
could  replace  readiness  as  a  primary  objective.  Secondly,  a  LCC  model 
could  be  adapted  to  calculate  availability.  A  thud  finding  was  that  the  added 
factor  of  availability  improved  the  Program  Manager's  (PM)  design  decision 
process.  Lastly,  the  LCC  management  concept  could  provide  stronger 
support  for  the  DoD  acquisition  objectives  by  equally  balancing  availability 
instead  of  supportability  with  cost,  schedule,  and  performance. 

Glassman,  Ned  and  Esperanza  Rodriquez,  Hughes  Aircraft  Co.,  "Less  Reliability  and 

Maintainability  ...  Not  More  ...  Is  Better  (Effectively  Applying  R&M  Influences  to  the 

Design  Process),"  IEEE ,  1989  Proceedings,  Annual  ReliabUity  and  Maintainability 

Symposium,  Atlanta,  GA,  24-26  January,  pp  210-215. 

Ineffective  communication  is  the  basis  for  many  organizational  problems. 

The  author's  opinion  is  that  the  "ilities"  difficulty  to  effectively  influence  the 
design  community  also  results  from  the  lack  of  effective  communications 
due  to  arbitrarily  established  boundaries. 

This  paper  offers  a  solution  in  work  at  Hughes  Aircraft  Company,  which 
focuses  on  the  problem  of  communication  between  the  "ilities"  and  the 
design  community.  The  solution,  the  Supportability  Design  Evaluation 
System  (SDES),  recognizes  that  the  result  of  effective  communication  can 
be  achieved  by  reducing  the  need  to  communicate. 
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This  solution  embeds  reliability  and  maintainability  analytical  tools  directly 
into  the  designer's  CAD/CAE  workstations.  This  provides  the  designer  on¬ 
line  capability  to  evaluate  his  design  in-process  and  to  capture  "ilities" 
improvements  before  metal  is  cut,  mind-sets  are  established,  and  while  time 
is  available  to  do  so. 

New  technological  solutions,  such  as  the  SDES,  also  requires  new 
approaches  to  organizational  structure,  responsibilities,  and  procurement 
practices  to  be  totally  successful. 

Only  by  understanding  and  isolating  the  root  cause  of  the  problem,  offering 
solutions  that  address  the  problem  outside  the  context  of  today's 
organizational  culture  and  design  process,  and  being  ready  to  accept  the 
likely  changes,  can  industry  effectively  meet  the  challenge  of 
competitiveness  and  more  effective  products.  The  "ilities"  communities 
must  join  in  a  proactive  effort  to  make  this  happen. 

Good,  Debra  E.,  "An  Analysis  of  the  Feasibility  of  Using  Design  Stability  as  a  Decision 
Parameter  for  Making  Logistics  Supportability  Decisions,"  A  Thesis,  LSSR-84-83,  Air 
Force  Institute  of  Technology,  September  1983,  Wright-Patterson  AFB,  OH.,  Defense 
Technical  Information  Center,  Alexandria,  VA. 

This  research  investigated  the  criteria  and  analysis  techniques  that  are 
currently  being  used  in  the  Air  Force  to  evaluate  design  stability  as  it  relates 
to  decisions  concerning  the  establishment  of  an  organic  logistics  support 
capability  versus  the  use  of  ICS.  The  analysis  was  conducted  in  two  parts: 

(1)  a  time  series  analysis  of  engineering  change  proposals  (ECPs)  which 
impacted  logistics  elements,  and  (2)  a  series  of  interviews  designed  to 
assess  the  adequacy  of  available  techniques  for  determining  the  point  at 
which  design  stability  is  achieved.  Results  of  the  ECP  trend  analysis 
indicate  that  while  time  series  analysis  can  be  used  to  define  a  model  for  a 
given  set  of  historical  data,  the  models  for  two  very  similar  systems,  the  F- 
15  and  F-16  fire  control  and  flight  control  avionics,  are  entirely  different 
Thus,  one  cannot  use  a  model  developed  with  historical  data  from  one 
program  to  predict  the  ECP  trend  for  a  new  program.  Results  of  the 
interviews  indicate  there  is  no  concensus  as  to  how  to  define  design 
stability.  Recommendations  include:  (a)  another  study  be  performed  to 
replicate  the  results  of  this  effort,  and  (b)  revision  of  AFR  800-21  be 
considered  to  reflect  these  results. 

Greeley,  Brendan  M.  Jr.,  "Air  Force  Delays  Programs  to  Enforce  Systems  Reliability,' 
Aviation  Week  and  Space  Technology ,  9  December  1985,  pp.  16-17. 

Greene,  David  C.  and  E.  Edward  Lowery,  "Supportability  Control  Factors,"  Proceedings 
of  the  1986  IEEE  Annual  Reliability  and  Maintainability  Symposium,  Las  Vegas,  NV.,  28- 
30  January  1988,  pp.  133-138. 

Supportability  is  difficult  to  define  and  describe  since  it  deals  with  a  large 
number  of  disciplines  under  varying  circumstances.  However,  through  the 
use  of  the  conventional  system  effectiveness  control  indices  (Availability, 
Dependability,  and  Capability),  supportability  factors  can  be  monitored  and 
combined  to  form  the  supportability  measure.  A  case  is  illustrated  to 
demonstrate  how  supportability  can  be  measured,  and  calculations  are 
given. 


Supportability  can  be  quantified  through  a  build-up  of  factors  that  are 
associated  with  the  system  effectiveness  measures  of  availability, 
dependability,  and  capability.  The  qualitative  factors  that  impact  the  R&M 
can  be  identified,  associated,  and  monitored  as  regarding  their  influence  or 
the  measures.  Other  ILS  factors  can  likewise  be  managed  to  assure  the 
desired  outcome. 

Supportability  can  be  "designed-to"  by  virtue  of  control  over  the  R&M 
characteristics  of  the  system  attained  through  logistics  analysis.  Control 
over  other  contributing  program  factors  is  possible  through  the  proper 
management  of  the  functions  that  are  involved  in  producing  logistics 
products  and  services. 

Griffin,  Col  Larry  (Office  of  the  Assistant  Secretary  of  Defense,  Production  and  Logistics, 
Washington,  DC)  Moderator,  Edward  Haug  (University  of  Iowa),  William  Henry  (Boeing 
Aerospace),  Dennis  Hoffman  (Texas  Instrument),  Larry  Linton  (Litton  Amecom),  and  Joe 
Meridith  (Newport  News  Shipbuilding  Co.),  Panelists,  "Panel  on  Computer-Aided 
Acquisition  and  Logistics  Support  (CALS)/RAMCAD,"  IEEE,  1989  Proceedings,  Annual 
Reliability  and  Maintainability  Symposium,  Atlanta,  GA,  24-26  January,  pp  403-404. 

Gulcher,  Robert  H.,  Rockwell  International,  "B-1B:  Designing  for  Supportability," 
Aerospace  America,  June  1984,  pp.  54-56,  Technical  Information  Services,  American 
Institute  of  Aeronautics  and  Astronautics. 

Historically,  design  efforts  focused  mainly  on  flight  performance.  Features 
that  would  have  improved  supportability,  such  as  test  connectors,  access 
doors,  and  component  packaging,  were  often  not  included  in  an  aircraft 
design  because  they  would  have  detracted  from  performance  by  adding 
weight  Squeezing  additional  performance  out  of  a  design  led  to  frequent 
failures  that  ultimately  aggravated  the  supportability  problem.  Furthermore, 
maintainability  engineers,  who  were  traditionally  responsible  for  identifying 
supportability  requirements,  worked  outside  the  engineering  design  groups, 
thus  limiting  their  effectiveness  in  establishing  supportability  requirements 
during  design.  Consequently,  aircraft  often  depended  heavily  on  ground 
support  systems,  increasing  support  costs  and  reducing  both  availability  and 
flexibility. 

Experience  on  the  B-1B  program  suggests  that  supportability  of  future 
aircraft  can  be  further  improved  by  fully  integrating  supportability 
requirements  into  design  from  conceptual  design  through  planning  of 
ground  operations  and  support.  Such  a  total  systems  approach  will  ensure 
early  identification  of  supportability  requirements. 

Once  the  supportability  requirements  are  identified,  various  design 
technologies  can  be  applied  to  meet  them.  A  self-sealing  hydraulic  actuator 
for  example,  could  be  used  on  future  aircraft.  In  some  cases  redundant 
seals  have  increased  the  interval  between  repairs  of  actuators.  High- 
performance  APUs  would  improve  self-sufficiency  for  engine  start,  ground 
test,  and  servicing,  and  could  also  reduce  aircraft  weight  and  simplify 
power  and  cooling  systems  needed  for  ground  maintenance.  A  third 
example  would  be  materials  and  techniques  for  quick  onboard  structural 
repair  without  compromising  aircraft  hardness  or  increasing  radar  cross- 
section. 
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Gunning,  David  R.,  "Integrated  Maintenance  Information  System,"  Preliminary  Draft, 
Combat  Logistics  Branch,  Logistics  and  Human  Factors  Division,  Air  Force  Human 
Resources  Laboratory,  Wright-Patterson  AFB,  Ohio,  27  January  1984. 

The  Air  Force  is  currently  developing  several  computer  systems  for  base- 
level  maintenance.  Unless  integration  occurs,  the  Air  Force  of  the  future 
will  have  several  computer  systems  and  updating  requirements  on  the  flight 
line.  Confusion  will  occur  with  possibly  incompatible  hardware,  data 
requirements,  and  required  technician  training.  The  Integrated  Maintenance 
Information  System  (IMIS)  will  integrate  the  existing  and  developing 
systems  with  the  automated  technical  data  system,  adding  diagnostic  job 
aids  to  increase  the  ability  of  technicians  to  troubleshoot  and  perform  a 
wider  range  of  maintenance  actions.  The  Integrated  Maintenance 
Information  System  will  develop  an  integrated  approach  to  total  weapon 
system  maintenance.  Technical  data,  training,  diagnostics,  management, 
scheduling,  and  historical  data  bases  will  be  linked  together,  and  a  portable 
graphic  display  will  be  developed  to  carry  and  present  the  required 
information  at  the  job  site.  Interfaces  will  be  developed  for  aircraft 
computers  and  for  existing  and  emerging  data  bases.  The  first  complete 
application  of  this  technology  will  be  on  the  Advanced  Tactical  Fighter.  The 
IMIS  goal  will  be  to  develop  one  system,  one  data  base,  one  user  interface 
device,  and  one  piece  of  output  hardware  that  flight  line  technicians  can  use 
to  do  timely  and  accurate  maintenance. 

Hindes,  D.  Kent,  Gary  A.  Walker,  and  David  H.  Wilson,  "Phase  HI  Study,  Development 
of  Maintenance  Metrics  to  Forecast  Resource  Demands  of  Weapons  Systems,"  Final 
Report,  Boeing  Aerospace  Company,  Product  Support,  Experience  Analysis  Center, 
Seattle,  WA,  February  1982. 

This  report  describes  the  methodology  and  results  of  a  15-month  Phase  HI 
effort  to  "Develop  Maintenance  Metrics  to  Forecast  Resource  Demands  of 
Weapons  Systems."  Increased  concern  with  the  rising  cost  to  support 
weapon  systems  currently  in  operation,  as  well  as  those  in  development, 
has  created  the  need  for  more  accurate  methods  of  projecting  maintenance 
requirements.  The  objective  of  this  subject  research  was  to  alleviate  the 
above  need  by  identifying,  determining,  and  integrating  those  measurable 
weapon  system  parameters  that  are  necessary  and  sufficient  to  predict  and 
quantify  the  drivers  of  maintenance  resource  demands. 

Irwin,  J.F.,  Northrop  Corp.,  "Operational  Readiness  and  its  Impact  on  Fighter  Avionic 
System  Design,"  Advanced  Concepts  for  AvionicstWeapon  System  Design,  Development 
and  Integration:  Conference  Proceedings  of  the  45th  Avionics  Panel  Symposium,  Ottawa, 
Canada,  18-22  April  1983,  AD-A138  600,  pp.  3-1  -3-12,  Defense  Technical  Information 
Center,  Alexandria,  VA. 

Operational  Readiness  (OR)  is  a  widely  used  term  that  covers  various 
aspects  of  availability,  maintainability,  reliability,  and  testability. 

Just  as  the  development  of  avionic  systems  require  the  establishment  of 
system  engineering,  software  design  and  interface  management  guidelines, 
the  same  requirement  exists  for  the  world  of  operational  readiness.  These 
OR  guidelines  include  the  following  controllable  elements: 

-  Design-for-Testability  (DFT) 

-  Operational  Fault  Tolerance 


-  System  Diagnostic  and  Reconfiguration 

-  Post-Flight  Data  Extraction/Analysis,  and 

-  Integrated  Test  and  Maintenance 

Design  and  Acquisition  of  systems  and  prime  electronic  equipment  must 
account  for  early  consideration  of  testability  and  automatic  test  design 
requirements.  Testability  factors  influence  all  phases  of  design,  integration, 
deployment  and  support  of  electronic  equipment  and  will  adversely  impact 
weapon  system  availability  and  ultimate  return  on  investment  if  improperly 
specified  and  implemented. 

The  major  goals  of  fault  tolerant  systems  are  increased  weapon  systems 
availability,  mission  survivability,  and  an  affordable  life  cycle  cost. 
Widespread  acceptance  of  operational  readiness  objectives  will  probably  be 
predicated  on  the  demonstrated  life  cycle  cost  of  those  initial  aircraft 
containing  fault  tolerant  systems. 

New  technologies,  such  as  Very  Large  Scale  Integrated  (VLSI)  and  Very 
High  Speed  Integrated  Circuits  (VHSIC),  will  have  a  major  impact  on 
tomorrow's  operational  effectiveness,  provided  the  OR  concepts  are  clearly 
defined  and  enforced.  Processing  elements,  virtual  memory  techniques, 
and  wideband  buses  are  readily  available  for  the  next  generation  fighter. 

The  design  of  weapon  system  computers  capable  of  tolerating  random 
hardware  failures,  has  become  a  relatively  mature  technology  at  an 
affordable  cost.  However,  full  advantage  must  be  taken  of  advances  in 
computer  technologies  to  integrate  a  fault  tolerant  design.  Today,  adequate 
methods  exist  to  insure  a  high  degree  of  availability  and  mission  success 
through  simple  Built-in-Test  (BIT)  and  auto-reconfigurable  designs.  This 
paper  provides  a  managerial  and  technical  roadmap  for  accomplishing  the 
desired  operational  readiness  goals  in  the  next  generation  fighter.  The 
contribution  of  the  various  attributes  (including  testability,  avionic 
architecture,  fault  tolerant  designs,  BIT,  standardization  and  operational 
readiness  control)  is  provided. 

Jones,  James  V.,  "Engineering  Design,  Reliability:  Maintainability  and  Testability,"  TAB 
Professional  and  Reference  Books,  Division  of  TAB  BOOKS,  Inc.,  Blue  Ridge  Summit, 
PA,  1988. 

Lappin,  Michael  K.,  MCAIR,  "Supportability  Evaluation  Prediction  Process,"  Proceedings 
of  the  1988  IEEE  Annual  Reliability  and  Maintainability  Symposium,  Los  Angeles,  CA., 
26-28  January  1988,  pp.  102-107. 

This  paper  describes  the  research  efforts  conducted  under  IRAD  Project 
Description  7-900,  Supportability  Evaluation  Prediction  Process.  A 
methodology  has  been  developed  that  allows  identification  of  supportability 
design  criteria  (SDC)  and  quantification  of  total  field  logistics  support 
requirements.  Interface  with  design  engineers  via  computer  aided  design 
(CAD)  workstations  is  also  described.  Specific  development  efforts 
include:  a  maintenance  discrepancy  data  base  (MDDB),  that  is  used  to 
provide  cause  and  effect  relationships;  impact  of  associated  maintenance 
tasks;  automated  like  and  similar  analysis  capabilities;  and  use  of  the 
expended  maintenance  importance  ratio  (EMIR). 

This  methodology  allows  the  development  of  predictive  R&M  values,  based 
on  design  team  evaluations,  to  be  available  during  the  pre-concept  phase  of 
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any  design  program.  The  method  takes  advantage  of  the  design  freedom 
available  during  the  pre-concept  phase,  determines  the  correct  support 
system,  and  helps  guide  the  design  process  to  reduce  O&S  costs.  MCAIR 
has  implemented  this  methodology  and  embedded  a  simulation  analysis 
process  to  provide  a  measure  of  cost  and  availability  for  any  proposed 
design.  This  stochastic  process  measures  the  potential  improvements  in 
R&M  and  determines  die  best  fit  of  manpower,  spares,  and  support 
equipment  for  a  given  support  posture.  This  approach  allows  MCAIR  the 
ability  to  provide  a  thorough  supportability  analysis  for  any  given  R&M 
parameters  during  the  pre-concept  phase,  thereby  ensuring  a  reduction  in 
cost  due  to  reducing  eventual  retrofits,  and  a  more  supportable  weapon 
system. 

Lauder,  R.P.F.,  "A  Practical  Example  of  Reducing  Life  Cycle  Costs  and  Increasing 
Availability,"  Design  for  Tactical  Avionics  Maintainability,  Advisory  Group  for  Aerospace 
Research  and  Development,  AGARD  Conference  Proceedings  No.  361,  NATO,  Copies  of 
papers  presented  at  the  Avionics  Panel  47th  Symposium  held  at  Quartier  Reine  Elisabeth, 
Brussels,  Belgium,  7-10  May  1984. 

The  principles  underlying  effective  operational  availability  are  explored  and 
quantified.  It  is  shown  that  although  large  sums  of  money  are  expended  on 
producing  reliable  components,  these  are  vitiated  if  the  end  equipment  is  not 
exposed  to  a  reliability  growth  program  (RGP),  because  only  10  percent  of 
the  calculated  MTBF  will  be  realized  in  practice.  It  is  claimed  that  costs  can 
be  reduced  by  using  common  commercial  components  without  loss  of 
MTBF  provided  it  is  followed  by  RGP. 

A  practical  example  is  given  of  the  expensive  and  time  consuming  steps  that 
have  to  be  taken  in  rescuing  a  low  MTBF  radar  and  increasing  its 
availability.  The  steps  and  the  methodology  leading  to  them  are  described 
and  the.  results  shown  (there  are  five  figures  and  two  references). 

Lemer,  Eric  J.,  "Avionics  Unreliability  Turns  Fighters  into  Shop  Queens,"  Aerospace 
America,  August  *985,  pp.  68-71. 

Aerospace  America  obtained  from  the  Air  Force  maintenance  records  for 
major  avionics  systems  on  a  number  of  fighter  aircraft-F-15,  F-16,  F-4,  F- 
111,  and  A-7.  The  data  showed  that  avionics  are  a  major,  and  in  some 
cases  the  major,  contributor  to  the  maintenance  requirements  of  these 
aircraft.  Maintaining  the  avionics  is  in  fact  a  key  limiting  factor  on  their 
sortie  rates,  especially  for  the  F- 15. 

Only  a  few  avionics  systems  accounted  for  the  largest  share  of  this 
maintenance  burden.  Some  of  these  systems,  such  as  the  fire-control  radar 
for  the  F- 15  and  F-16,  spend  as  much  time  in  the  shop  as  in  flight.  The  F- 
15  fire  control  system,  for  example,  required  maintenance  after  about  6 
hours  of  use,  and  each  repair  took  an  average  of  15-20  manhours. 

Loose,  Capt  Donald  R.,  USAF,  "Design  for  Maintainability,  What  Government  Standards 
Do  and  Don't  Say,"  Air  Force  Human  Resources  Laboratory  Technical  Paper,  AFHRL-TP 
89-28,  Wright-Patterson  AFB,  OH.,  January  1989. 

This  literature  survey  contains  no  new  technical  information  but  rather 
consolidates  already  existing  Government  guidance  on  Design  For 
Maintainability  (DFM).  Unfortunately,  DFM  expertise  is  scattered  among 
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references  from  several  engineering  and  logistics  disciplines.  Application  in 
the  weapon  system  acquisition  process,  therefore,  is  equally  fragmented. 

Consolidating  this  information  serves  two  goals.  First,  it  will  be  easier  to 
access  and  apply.  Second,  it  will  be  easier  to  determine  what  parts  of  this 
expertise  are  still  weak  within  Government  These  areas  should  be  the 
focus  of  the  acquisition  logistics  research  community. 

Lyman,  Jerry,  "Reliability  Gets  Promotion,"  Electronics  Week ,  11  March  1985,  pp.  til- 
67. 

The  Annual  Reliability  and  Maintainability  Symposium,  which  was  held  on 
January  1985,  spotlighted  the  efforts  of  the  military  and  its  vendors  to 
increase  field-reliability  performance.  The  papers  that  were  presented  at  the 
conference  dealt  with  some  of  the  most  advanced  signal-processing  and 
avionics  systems  reaching  the  three  Services.  Covered  were  the  rarely 
discussed  topic  of  maintenance- induced  failures  and  integrated  diagnostics, 
including  built-in  test  equipment  and  artificial  intelligence. 

For  the  military,  the  bottom  line  in  electronic  equipment  is  performance  in 
the  field.  What  counts  to  the  service  personnel  who  maintain  this  equipment 
is  actual  MTBFs.  Two  case  histories  described  at  the  symposium  give  a 
detailed  look  at  two  recent  electronic  systems— an  IBM  Corporation 
advanced  signal  processor  and  a  General  Electric  Company  flight-control 
computer-under  actual  field  conditions.  The  results  are  presented  in  this 
paper. 

Maintenance  of  Supplies  and  Equipment ,  DARCOM  Guide  to  Logistic  Support  Analysis, 
DARCOM-P  750-16,  Headquarters,  U.S.  Army  Materiel  Development  and  Readiness 
Command,  June  1980. 

This  pamphlet  is  intended  for  use  in  developing  logistic  support  analysis 
(LS  A)  programs  and  logistic  support  analysis  records  (LSAR)  for  materiel 
acquisition  programs  in  the  U.S.  Army  Materiel  Development  and 
Readiness  Command  (DARCOM).  It  is  intended  for  use  in  conjunction 
with  MIL-STD- 1388-1  and  MIL-STD- 1388-2,  Logistic  Support  Analysis, 
for  both  Government-conducted  and  contractor-conducted  LSA  and  LSAR 
efforts. 

Management  Sciences,  Inc.,  Predictor/Resuits/Fracas,  R,  M,  and  L  Design  Techniques, 
Albuquerque,  NM,  June  1984. 

The  use  of  computer  aided  design,  and  computer  aided  manufacturing 
(CAD/CAM)  is  developing  at  a  rapid  pace.  The  Government-Industry  joint 
study  group  on  computerized  techniques  are  reviewing  the  analytical  powers 
of  CAD/CAM  software  with  regard  to  reliability,  maintainability,  and 
logistics  (R,M  and  L).  PREDICTOR  covers  many  of  the  aspects  the  group 
is  interested  in  as  the  development  of  PREDICTOR/RESULTS/FRACAS 
has  been  user  driven  to  meet  die  generic  needs  of  managers  and  technicians. 

This  synopsis  is  written  to  provide  direct  relationships  to  the  tasks  outlined 
in  the  study.  Also  included  are  discussions  about  IDEALS.  IDEALS  is  the 
unification  program  that  ties  the  other  programs  together. 

Mascarenhas,  Jose  M.G.B.,  "ATE  User's  View  on  Design  for  Maintainability,"  Design  for 
Tactical  Avionics  Maintainability,  Advisory  Group  for  Aerospace  Research  and 
Development,  AGARD  Conference  Proceedings  No.  361,  NATO,  Copies  of  papers 
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presented  at  the  Avionics  Panel  47th  Symposium  held  at  Quartier  Reine  Elisabeth, 
Brussels,  Belgium,  7-10  May  1984. 

This  paper  first  describes  the  main  features  of  the  ATE  that  PoAF  is  using. 
Emphasis  is  put  on  the  hardware  and  software  capabilities  and  limitations. 

The  paper  examines  some  of  the  techniques  available  for  test  program 
generation  and  validation.  Finally,  the  paper  presents  the  author’s 
viewpoint  on  board  design  for  maintainability  (particularly  with  ATE). 

Nelson,  J.R.,  P.  Konoske  Dey,  M.R.  Fiorello,  J.R.  Gebman,  G.K.  Smith,  and  A. 
Sweetland,  "A  Weapon-System  Life-Cycle  Overview:  The  4-7D  Experience,"  The  Rand 
Corporation,  Santa  Monica,  CA,  a  report  prepared  for  the  U.S.  Air  Force,  R-1452-PR, 
October  1974. 

This  study  focuses  primarily  on  a  comparison  of  test-phase  results  with  the 
subsequent  operational  experience  of  the  A-7D  attack  aircraft  to  determine 
when  component  reliability  and  maintenance  problems  were  revealed,  what 
kinds  of  problems  showed  up  in  the  various  stages  of  the  weapon-system 
life  cycle,  and  the  impact  these  problems  had  on  operational  availability  and 
operating  cost  It  is  found  that  earlier  correction  of  critical  problems  should 
reduce  operational  and  maintenance  costs  and  increase  the  capability  of  the 
system  enough  to  permit  a  net  improvement  in  the  overall  capability  life- 
cycle  cost  of  the  system.  An  extended,  comprehensive  Initial  Operational 
Test  and  Evaluation  would  allow  identification  of  additional  reliability  and 
maintenance  problems.  A  better  approach  to  development  of  avionics 
components  and  related  software  is  needed.  Finally,  data  systems  should 
be  improved  as  necessary  and  exploited  more  fully. 

Oldfield,  D.  and  L.T.J.  Salmon,  "A  Future  System  Design  Technique  Based  on  Functional 
Decomposition,  Supported  by  Quantifiable  Design  Aids,  and  Guidelines  for  Minimum 
Maintenance  Costs,"  Advanced  Concepts  for  Avionics/Weapon  System  Design, 
Development  and  Integration:  Conference  Proceedings  of  the  45th  Avionics  Panel 
Symposium,  Ottawa,  Canada,  18-22  April  1983,  AD-A138  600,  pp.  3-1  -3-12,  Defense 
Technical  Information  Center,  Alexandria,  VA. 

The  increasing  cost  and  complexity  of  modem  fast-jet  aircraft,  coupled  with 
the  long  development  period  which  takes  place  while  technology  is 
changing  rapidly,  make  it  necessary  to  consider  a  new  approach  to  system 
design.  Such  an  approach  should  be  based  on  a  structured  top-down 
procedure,  in  which  the  rather  general  requirement  can  be  changed  into  a 
detailed  documented  design  in  a  controlled  manner. 

One  important  aspect  of  design  is  cost,  and  in  particular  cost-effectiveness 
and  life-cycle  cost.  At  least  some  of  the  design  aims  can  be  based  on  cost- 
effectiveness  reasoning,  and  it  is  necessary  to  have  an  appreciation  of  the 
background  to  this.  Reliability-dependent  maintenance  costs  can  amount  to 
much  more  than  the  original  purchase  price,  and  hence  it  is  essential  to  be 
aware  of  the  possible  cost-drivers,  and  include  maintenance  aspects  in  the 
design  approach  from  the  beginning. 

This  paper  describes  some  of  the  work  carried  out  at  the  Royal  Aircraft 
Establishment  (RAE)  on  these  aspects. 

Palazzo,  C.J.  and  M.M.  Rosenfeld,  Grumman  Aerospace  Corporation,  "Avionics  Built-In- 
Test  Effectiveness  and  Life  Cycle  Cost,"  AIAA  Aircraft  Design,  Systems  and  Technology 
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Meeting ,  17-19  October  1983,  Fort  Worth,  TX,  AIAA-83-2448,  Technical  Information 
Service,  American  Institute  of  Aeronautics  and  Astronautics,  New  York,  NY. 

Results  of  an  investigation  into  the  effectiveness  of  built-in-test  (BIT)  on 
aircraft  weapon  systems  and  its  impact  on  operational  assessability  and  life 
cycle  cost  (LCC)  are  presented  herein.  BIT  effectiveness  was  found  to  be 
high  in  current  operational  systems  although  errors  in  data  collection  and 
interpretation  precluded  highly  accurate  measurements.  Low  BIT 
effectiveness  had  a  negligible  effect  on  logistic  support  costs  (LSC), 
particularly  for  avionic  units  with  moderate  to  high  reliabilities.  It  was 
concluded  that  a  major  reason  for  improving  BIT  effectiveness  was  to 
increase  its  ability  to  determine  the  status  of  mission  essential  subsystems 
(Le.,  increase  operational  assessability). 

Priest,  John  W.,  Engineering  Design  for  Producibility  and  Reliability,  Marcel  Dekker, 
Inc.,  New  York  and  Basel,  1988. 

Focusing  on  the  engineering  methodologies  and  practices  that  can  improve 
any  product's  producibility,  reliability,  and  quality,  this  useful  reference/text 
shows  how  these  elements  can  be  designed  into  an  item  during  product 
development.  For  each  practice  the  book  explains  why  it  is  important, 
reviews  its  methodologies,  and  gives  design  techniques  helpful  for 
successful  implementation. 

Thompson,  Steven  A.,  "Relating  Life  Cycle  Costs  to  Weapon  System  Effectiveness:  An 
Integrated  Approach,"  Proceedings  of  the  IEEE  1978  National  Aerospace  and  Electronics 
Conference,  NAEON  78,  Dayton,  OH,  16-18  May  1978,  pp.  1083-4. 

Although  cost-effectiveness  analyses  have  received  much  emphasis  within 
the  Department  of  Defense  for  the  past  two  decades,  one  seems  to  encounter 
a  void  when  attempting  to  find  examples  of  analyses  accomplished  at  the 
weapon  system  level.  This  paper  describes  the  problems  involved  in  an 
analysis  of  this  magnitude,  some  steps  that  can  be  taken  to  make  it  a  more 
tractable  task,  and  a  proposed  research  project  to  develop  a  system 
effectiveness  structure  relating  the  reliability  characteristics,  maintainability 
features,  life  cycle  cost  estimates,  and  performance  measures  of  the  various 
subsystems  of  a  weapon  system  to  an  overall  system  effectiveness  measure. 

Topics  in  Reliability  and  Maintainability  and  Statistics,  Consolidated  Lecture  Notes, 
Tutorial  Sessions,  1989  Annual  Reliability  and  Maintainability  Symposium. 

These  Tutorial  Notes  consist  of  expository  material  prepared  by  the 
instructors  for  the  tutorial  sessions.  The  notes  for  each  session  are 
reviewed  each  year  to  assure  currency,  accuracy,  and  applicability. 

van  der  Mooren,  A.L.,  Eindhoven  University  of  Technology,  Eindhoven,  The 
Netherlands,  "Maintenance  Aspects  in  Design  of  Mechanical  Systems,"  Proceedings  of  the 
Institution  of  Mechanical  Engineers,  International  Conference,  Engineering  Design, 
Volume  1, 22-25  August  1989,  Harrogate  International  Centre,  pp.  1227-1238. 

Walker,  R.K.,  Northrop  Aircraft  Division,  "Built- In-Test  (BIT)  Utilization  for  Improved 
Supportability  of  the  F-  0  Aircraft,"  Proceedings  of  the  International  Automatic  Testing 
Conference,  Uniondale,  NY.,  22-24  October  1985  (A 86-43876  21-61),  New  York, 
IEEE,  pp.  446-449. 

Complex  avionics  systems  of  the  past  have  been  accompanied  by  major 
support  problems.  The  early  integrated  systems  of  the  1960's  resulted  in 
large  and  expensive  test  systems  both  at  the  organizational  and  intermediate 
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maintenance  levels.  The  1970's  followed  with  built-in-test  (BIT)  to 
accomplish  much  of  the  organizational  level  fault  isolation  and  more 
complex  and  expensive  automatic  test  equipment  at  the  intermediate  level. 

The  problems  multiplied  when  the  BIT  created  additional  support  problems 
because  of  the  "Re-Test-OKs,"  "Can-not-Duplicates,"  and  "False  Alarms." 
Fortunately  this  trend  is  being  reversed.  The  technology  of  the  1980's  is 
embodied  in  the  Fl-20  Tigershark.  Its  avionics  equipment  utilizes  BIT  to 
achieve  the  long  sought  low  cost  supportability  in  addition  to  outstanding 
performance. 

Webster,  L.R.  and  J.M.  Mader,  Harris  Satellite  Communications  and  Government 

Aerospace  Systems  Divisions,  "VLSI  Impact  on  RAMS  Strategies  in  Avionics  Design," 

Proceedings  of  the  1986  IEEE  Annual  Reliability  and  Maintainability  Symposium ,  Las 

Vegas,  NV.,  28-30  January  1986,  pp.  303-306. 

This  paper  discusses  the  impact  of  Very  Large  Scale  Integrated  Circuits 
(VLSI)  on  the  Reliability,  Availability,  Maintainability,  and  Supportability 
(RAMS)  characteristics  of  avionics  systems  to  be  deployed  in  the  1990  time 
frame.  A  reliability  sensitivity  analysis  of  a  4.5  million  gate  system  is 
presented  with  data  from  more  than  25  major  system  redundancy 
configurations  analyzed.  The  impact  of  these  various  redundancy 
architectures  on  chip,  module,  equipment  and  system  RAMS  characteristics 
is  detailed. 

Using  this  medium-sized  digital  equipment  analysis  as  a  model,  we  proceed 
to  uncover  the  implications  of  dramatically  increased  use  of  custom  VLSI  in 
avionics  (and  other)  systems.  The  purpose  is  to  provide  RAMS 
practitioners  with  some  insight  into  the  design  and  use  implications  of  the 
"Super-chips"  that  will  soon  become  commonplace. 

Some  of  the  conclusions  are:  (1)  non-monolithic  interconnections  essentially 
determine  system  reliability,  (2)  increased  chip  complexity  provides  high 
leverage  RAMS  opportunities,  (3)  RAMS  personnel  must  cause 
communication  to  happen  between  systems  definition  and  VLSI 
implementation  personnel  if  the  full  potential  of  VLSI  is  to  be  realized,  and 
(4)  there  are  tough  design  challenges  in  thermal,  electrostatic  discharge 
radiation  protection  and  circuit/system  architecture  which  must  be  met  in  the 
design,  production,  and  support  of  systems  using  these  devices. 
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COMPUTER  SUPPORT  FOR  RELIABILITY  AND 
MAINTAINABILITY  MODELING 


The  University  of  Maryland  Center  for  Computer-Aided  Life  Cycle  Engineering 
(CALCE)  system  for  electronics  equipment  design  software  consists  of  an  artificial 
intelligence  (AI)  executive  editor  and  controller  coupled  to  a  decision  support  shell  that 
integrates  various  design  and  analysis  tools  while  providing  transparent  data  and  design 
process  management  The  CALCE  system  supports  decision  making  by  the  design  team 
by  providing  a  framework  for  conducting  design  trade-offs  and  comparing  allocated  values 
against  design  requirements  and  constraints. 

This  appendix  is  a  type  of  user's  manual  for  the  Reliability  Modeling  and  the 
Maintainability  Modeling  modules  of  the  CALCE  system  used  in  the  demonstration  of  the 
methodology  given  in  this  paper. 

The  Reliability  Modeling  module  allows  the  creation  and  manipulation  of  a  model  to 
determine  part  and  system  reliability  based  on  part  failure  information.  The  current  system, 
assembly  or  circuit  board  being  modeled  is  termed  "active."  It  is  the  system  currently 
loaded  and  sitting  in  memory— its  name  is  displayed  in  the  upper  right  hand  comer  of  the 
computer  screen.  Parts  (referred  to  here  as  elements)  and  their  characteristics  are  entered 
individually  into  a  parts  list  to  form  a  configuration.  Complex  active  and  standby 
redundancies  as  well  as  P  out  of  Q  redundancies1  can  be  modeled.  From  a  given  mission 
time,  the  system  reliability  of  the  configuration  is  calculated,  and  a  block  diagram 
illustrating  the  system  configuration  can  be  displayed.  Systems  with  different  mission 
times  and  maintenance  visits  can  be  combined  and  treated  as  one.  Graphics  support  for 
conducting  trade-offs  include  plots  of  reliability  (series,  redundant,  and  redundant  with 
repair)  versus  mission  time  and  the  mean  time  between  critical  failures  (MTBCF)  versus  the 
number  of  maintenance  visits  per  year. 


1  A  "P  out  of  Q  redundancy"  means  that  there  are  Q  elements  in  parallel,  but  only  P  need  to  be  active  at 
one  time. 
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The  Maintainability  Modeling  module  can  be  used  to  create  a  detailed  model  of  the 
maintenance  required  for  the  system  being  designed.  The  module  includes  two  data  base 
managers.  The  first  can  create,  modify,  and  delete  generic  lists  of  elemental  maintenance 
tasks.  This  data  base  includes  a  50-character  description  of  the  task,  the  time  it  takes  to 
perform  the  task,  a  9-character  task  ID  number,  and  a  list  of  the  standard  element 
maintenance  tasks  defined  by  Rome  Air  Development  Center  (RADC).  The  second 
maintainability  data  base  is  a  system-specific  description  of  the  maintenance  tasks  required 
to  keep  the  system  in  operation.  This  data  base  includes  a  list  of  all  of  the  different  ways  in 
which  each  subsystem  can  fail.  Each  of  these  failure  modes  includes  a  50-character 
description  as  well  as  a  percentage  frequency  (the  percentage  of  the  total  subsystem  failures 
that  will  be  of  this  type  of  failure  mode).  For  each  failure  mode  there  is  a  subdata  base 
containing  a  list  of  the  elemental  maintenance  tasks  required  for  preparation,  isolation, 
disassembly,  interchange,  reassembly,  alignment,  checkout,  and  start-up  of  the  subsystem 
after  the  failure  has  occurred.  Included  in  this  data  are  the  manpower  requirements  and  the 
repetitions  for  each  task.  When  all  the  data  have  been  entered,  the  system  will  calculate  the 
different  maintainability  figures  of  merit  (FOMs)  for  the  system  as  set  out  in  Military 
Handbook  472. 

A.  RELIABILITY  MODELING 

The  reliability  tree  is  the  environment  from  which  all  aspects  of  the  reliability 
modeling  system  are  accessed.  The  tree  nodes  are  "Analysis,"  "Block  Diagram," 
"Reports,"  and  ’Tools."  Each  node  branches  from  the  heading  "Reliability"  (see  Figure  C- 
1). 


RELIABILITY  MODELING 


Figure  C-1.  Reliability  Tree 
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The  "Analysis"  node  allows  for  the  creation  and  manipulation  of  models  for 
determining  component  and  system  reliability.  The  "Block  Diagram"  node  provides  a 
graphic  display  of  the  model  in  block  diagram  form.  The  "Report"  node  generates  a  printed 
copy  of  the  reliability  data  for  the  model.  The  "Tools"  node  provides  easy  access  to 
independent  tools  used  with  Reliability  Modeling,  such  as  Pizzazz™  (a  graphics  package 
used  for  printing  good  quality  screen  images). 

The  arrow  keys  are  used  to  move  the  cursor  around  the  screen.  When  the  cursor  is 
on  a  node,  the  associated  label  in  that  node  turns  red.  To  enter  a  node,  move  the  cursor 
onto  the  node  and  press  <Enter>.  A  small  menu  that  displays  options  will  appear.  To 
choose  an  option,  use  the  up  and  down  arrow  keys  to  move  the  highlight  bar  to  the  option 
desired  and  press  <Enter>.  An  explanation  of  each  of  the  options  follows  (listed  under  its 
node).  To  exit  a  window  and  return  to  the  tree,  press  <Esc>.  To  exit  the  tree  and  return  to 
DOS,  press  <Esc>. 

Table  C-l.  Reliability  Tree  Options 


Node 

Option 

Function 

Reliability 

Notes 

provides  notes  about  the 
node 

Analysis 

Execute 

begins  the  reliability  modeling 
module 

Notes 

provides  notes  about  the 
node 

Block  Diagram 

Display 

begins  the  graphic  display 
module 

Notes 

provides  notes  about  the 
node 

Reports 

Execute 

begins  the  report  generator 

Notes 

provides  notes  about  the 
node 

Tools 

Pizazz  ON 

activates  the  memory  resident 
"Pizazz"  screen  capture  utility 

Pizazz  OFF 

deactivates  the  "Pizazz" 
screen  capture  utility 

Notes 

provides  notes  about  the 
node 
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B.  ANALYSIS  NODE 


The  reliability  modeling  module  is  entered  by  selecting  "Execute"  as  the  Analysis 
option.  When  the  reliability  modeling  module  begins,  the  parts  list  is  displayed  with  a  list 
of  options  across  the  top  of  the  screen  (Figure  C-2). 


RELIABILITY  MODEL  1 116  SysRel  u/R:9. 860934  Active :ARSR4DBH 

File  Edit _ Setup _ Parameters _ 6raphs _ XIT _ _ 


Block  Part  Description 

ID  ID 

Total 

Units 

Required 

Units 

Max-Hum 

Units 

al  SUFI  pulse  comp. 

2.9 

1 

1 

1 

a2  SUFZ  doppler  filter 

2.9 

1 

1 

1 

a3  SUF3  PD  I 

2.9 

1 

1 

1 

*4  SWF4  CFAR 

2.9 

1 

1 

1 

a5  SUP5  channel  interface 

2.9 

1 

1 

1 

a6  SUP6  AKSP  channel 

2.9 

7 

6 

7 

a?  SUF7  A  MSP  interface 

2.0 

4 

3 

4 

a6  SWP8  beacon  time  non  it. 

2.9 

2 

1 

2 

aS  SWP9  beacon  TTG 

2.9 

2 

1 

2 

a 10  SUP 10  beacon  code  extr. 

2.9 

2 

1 

Z 

all  BDF1  video  quantizer 

2.0 

2 

1 

2 

a 12  BDP2  defruiter 

2.0 

2 

1 

2 

al3  BDP3  bus/tx  beacon 

2.9 

2 

1 

2 

a 14  BDP4  bus/tx  tdy 

2.9 

2 

1 

2 

al5  BDPS  global  memory 

2.0 

2 

1 

2 

a 16  BDP6  global  memory 

2.9 

2 

1 

2 

Select  a  Data  File 


Figure  C-2.  Reliability  Modeling-Parts  List  and  Options 


I .  Parts  List 

Individual  parts  are  referred  to  as  LFEs  Gower  functional  elements).  A  grouping  of 
elements  is  called  a  CFE  (complex  functional  element).  LFEs  and  CFEs  require  block  IDs, 
part  IDs,  and  part  descriptions.  The  LFEs  and  CFEs  are  listed  separately  in  the  parts  list. 
An  LFE  may  not  be  placed  among  CFEs. 

Each  element  has  a  set  of  13  associated  attributes.  Three  of  these  attributes  are  used 
for  part  identification,  block  diagram  placement  designation  (block  ID),  and  part  description 
and  are  always  displayed  across  the  top  left  of  the  screen  as  shown  in  Figure  C-2.  All  but 


one  of  the  remaining  ten  attributes  require  numerical  values.  Four  of  these  values  are 
assigned  by  the  user,  the  remaining  five  are  computed  from  other  attributes  and  may  not  be 
changed.  The  user  selects  which  of  the  ten  attributes  are  to  be  shown  on  the  screen  with 
the  "Select"  option,  discussed  in  Section  2.a. 

a.  Distribution 

The  distribution  specifies  the  mathematical  model  assumed  for  the  failure  rate  of  the 
elements.  The  failure  density  function  is  a  general  model  for  the  distribution.  The  failure 
density  function,  f(t),  is  defined  as 

fit)  =  (1/N)  (dM/dt)  =  -dR/dt 

where  N  is  the  number  of  elements,  M  is  the  number  of  elements  that  have  failed,  and  R  is 
the  reliability  of  the  element.  The  exponential  distribution  is  designated  by  E.  It  assumes  a 
constant  failure  rate,  5,  given  in  failures  per  million  hours  (Fr/Mhr). 

b.  Total  Number  of  Elements 

A  default  value  of  one  is  assumed  for  each  LFE.  This  attribute  applies  to  parallel 
redundancies,  specifying  the  total  number  of  paths  or  elements  in  parallel. 

c.  Total  Number  of  Required  Elements 

A  default  of  one  is  assumed  for  each  LFE.  This  attribute  is  used  to  denote  P  out  of 
Q  required  elements  in  parallel.  For  example,  if  the  total  lumber  of  elements  is  three,  and 
the  number  of  required  elements  is  two,  then  two  out  of  three  must  be  operable  for  system 
success. 

d.  Element  Failure  Rate 

The  element  failure  rate  is  the  number  of  failures  per  million  hours,  obtained  from 
part  failure  information. 

e.  Series  Failure  Rate 

The  failure  rate  for  all  of  the  elements  in  the  CFE  (or  LFE  if  number  of  total 
elements  is  greater  than  one)  in  a  series  configuration  is  calculated  by 
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8  =  2^8(i) 

i=l 

f .  Percent  of  Total  Failure  Rate 

The  percent  of  the  total  failure  rate  is  the  failure  rate  of  the  element  per  the  total 
system  failure  rate. 

g.  Equivalent  Failure  Rate 

The  equivalent  failure  rate  is  the  failure  rate  the  configuration  would  have  if  it  were 
only  one  element.  This  value  is  calculated  from  the  equation 

RCFE  =  e-5 1 

Thus,  the  equivalent  failure  rate  8'  is  calculated  as 

8'  =  -  (lOfyt)  In  R-CFE 

h.  Duty  Cycle 

The  duty  cycle  is  the  ratio  of  the  element's  operating  time  to  that  of  the  system 
operating  time.  In  calculating  the  reliability  of  an  element  with  an  exponential  distribution, 
the  argument  of  the  exponent  is  multiplied  by  this  ratio  (see  Section  i). 

i .  Reliability 

The  reliability  is  the  probability  that  a  system  will  perform  satisfactorily  without 
repair  for  a  given  period  of  time  when  used  under  stated  conditions.  The  formula  for  the 
reliability  with  an  exponential  distribution  and  a  constant  failure  rate  8  is 

R(t)  =  e-^ 

where  d  is  the  duty  cycle  and  t  is  the  mission  time  in  hours. 

2 .  Options 

The  reliability  modeling  module  has  1 1  options  for  the  creation  and  manipulation  of 
models.  Options  are  functions  that  perform  specific  tasks,  such  as  adding  or  removing 
elements  or  changing  element  data.  They  are  displayed  across  the  top  of  the  screen.  Use 
the  arrow  keys  to  select  options  and  press  <Enter>  to  execute  them,  or  type  the  highlighted 
letter  of  the  chosen  option.  To  exit  an  option  and  return  to  the  main  menu,  press  <Esc>. 
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a.  Select 


"Select"  allows  the  operator  to  choose  which  of  the  ten  attributes  that  require  values 
are  displayed  on  the  screen.  Although  only  four  attributes  can  be  seen  on  the  screen 
simultaneously,  more  may  be  toggled  on.  From  the  list  in  "Select,"  the  first  four  toggled 
on  are  displayed.  The  attributes  toggle  off  and  on  with  the  <Enter>  key.  The  attributes 
toggled  on  are  liighlighted  on  the  "Select  Attributes"  screen.  All  of  the  attributes  toggled  on 
can  be  scrolled  through  in  any  of  the  options  that  allow  scrolling  (  "View,"  "Make," 
"Change").  At  least  four  attributes  must  always  be  toggled  on. 

b.  Add 

The  model's  parts  list  is  generated  in  the  function  "Add."  The  procedure  for  adding 
elements  to  the  parts  lists  is  as  follows.  Upon  entering  "Add,"  a  window  will  appear 
displaying  a  default  block  ID  name  for  an  LFE.  For  block  ID,  default  names  are  al,  a2, 
a3,  etc.  To  accept  the  default  name  press  <Enter>,  otherwise  type  another  name.  Block 
IDs  can  be  no  longer  than  four  letters.  Once  entered,  the  window  asks  for  a  part  ID  and 
then  a  part  description.  For  part  ID  and  part  description,  no  default  name  is  given  initially. 
The  previous  value  for  these  names  are  repeated,  however,  in  subsequent  LFEs.  The 
maximum  length  for  part  ID  is  six  letters  and  for  part  description  20  letters.  After  these 
three  names  have  been  entered,  press  <Enter>  to  insert  the  LFE  on  the  screen  after  the 
element  pointed  to  by  the  cursor.  The  default  position  for  LFEs  is  at  the  end  of  the  LFE 
list. 


c.  Make 

The  function  "Make"  is  used  to  develop  the  configuration  of  the  model  by  building 
CFEs.  Default  block  ID  names  are  assigned  to  CFEs.  Press  <Enter>  to  accept  the  default 
name  or  enter  another  name  and  press  <Enter>  (the  maximum  length  for  block  ID,  part  ID, 
and  part  description  for  CFEs  are  the  same  as  that  for  LFEs).  A  window  then  appears  so 
that  the  part  ID  may  be  defined.  No  default  name  for  part  ID  is  given  initially.  Type  the 
part  ID  and  press  <Enter>.  Now  enter  the  part  description  in  the  window  and  press 
<Enter>.  The  CFE  must  then  be  defined  to  describe  how  the  LFEs  will  be  arranged  in  the 
CFE.  A  descriptor  line  appears  at  the  bottom  of  the  screen  so  that  the  CFE  can  be  defin  1. 
The  syntax  for  defining  CFEs  is  parentheses  ( )  for  series  configurations,  brackets  [  ]  for 
parallel  redundancies,  and  curled  brackets  {  }  for  standby  redundancies.  Only  one  space 
between  elements'  block  IDs  is  required  to  distinguish  them  within  a  CFE.  Pressing  <F1> 
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provides  a  help  screen  for  CFE  syntax.  Press  <Enter>  when  the  definition  has  been 
entered.  Use  the  arrow  keys  to  position  the  CFE  in  the  parts  list  and  press  <Enter>  to  place 
the  CFE  on  the  screen  after  the  element  pointed  to  by  the  cursor.  A  CFE  may  be  included 
in  the  definition  of  another  CFE.  However,  a  CFE  may  not  be  placed  on  the  parts  list 
before  its  constituents. 

To  denote  the  number  of  required  operating  elements  when  the  elements  are 
different  (P  out  of  Q  in  a  parallel  redundancy),  put  a  colon  after  the  closing  brackets 
followed  by  the  number  of  required  elements.  If  the  number  of  required  elements  is  not 
specified,  a  default  value  of  one  will  be  assumed.  Example  arrangements  are  shown  in 


Table  C-2. 

Table  C-2.  Examples  of  the  Syntax  for  Placement  of  LFEs  within  CFEs 


Syntax 

Type 

Define  "ml":  (nl  n2  n3) 

a  series  arrangement  of  nl ,  n2,  and  n3  as  CFE 
ml 

Define  "b2":  [a5  a6] 

a  parallel  arrangement  of  a5  and  a6  as  CFE  b2 

Define  "b5":  ([b3  b4]  a12  a13) 

b3  and  b4  are  parallel  and  are  in  series  with  al  2 
and  a13,  and  the  CFE  name  is  b5 

Define  "cl":  [(bl  c2)  a7  a8] 

arranges  a7  and  a8  in  parallel  with  the  series 
combination  of  bl  and  c2,  and  the  CFE  name 
is  cl ;  the  total  number  of  elements  attribute  is 

3  and  the  required  number  of  elements 
attribute  is  2 

When  the  elements  in  parallel  are  identical,  the  "Total  Elements"  attribute  can  be 
used  to  denote  the  number  of  elements  in  parallel  and  the  "Number  of  Required  Elements" 
attribute  can  be  used  to  indicate  the  number  that  must  operate.  Thus,  for  identical  parallel 
redundancies,  the  number  of  total  and  required  elements  are  not  specified  in  the  definition 
of  the  CFE  but  are  indicated  using  the  attributes  associated  with  the  element.  By 
implementing  its  attributes,  an  LFE  can  be  placed  in  parallel  with  identical  ones  without 
having  to  make  a  CFE. 

Table  C-3  defines  various  configurations  of  CFEs.  (They  are  illustrated  in  the 
Reliability  Block  Diagram  shown  in  Figure  C-8.)  The  syntax  of  the  definition  of  CFE  "c2" 
denotes  that  LFEs  a9,  alO,  and  all  are  different  elements  and  that  two  out  of  three  are 
required.  In  CFE  "bl,"  however,  the  redundancy  has  been  implemented  using  the 
attributes  "Total  Number  of  Elements"  and  "Required  Number  of  Elements."  The  syntax 
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denote  that  each  path  is  identical,  so  that  CFE  "bl"  consists  of  two  paths  of  LFEs  al,  a2, 
and  a3  and  one  of  the  two  paths  is  required  for  system  success. 


Table  C-3.  Parallel  Redundancies 


Syntax 

Type 

Define  *d3":  [cl  c2  c3]:2 

2  out  of  3  elements  are  required  for  system 
success  where  cl ,  c2,  and  c3  are  each 
different  elements,  and  the  CFE  name  is  d3 

Define  "bl":  (at  a2  a3) 

a  series  arrangement  of  al ,  a2,  and  a3  as  CFE 
bf ;  the  total  number  of  elements  attribute  is  2 
and  the  required  number  of  elements  attribute 
is  1 

Define  "c2":  [a9  alO  at  1]:2 

2  out  of  3  elements  are  required  for  system 
success  where  a9,  alO,  and  all  are  each 
different  elements,  and  the  CRE  name  is  c2 

To  create  standby  arrangements,  enclose  the  block  IDs  of  the  elements  in  the 
standby  circuit  {  },  insert  a  space,  and  follow  with  the  block  IDs  of  the  switch  and  monitor 
elements  (which  must  be  LFEs).  Whether  the  average  or  worst  case  failure  rates  are  to  be 
used  in  calculations  must  be  specified  before  a  standby  CFE  can  be  added  to  the  parts  list. 
The  syntax  for  defining  a  CFE  containing  a  standby  arrangement  is  given  in  Table  C-4  and 
illustrated  in  Figure  C-3. 

Table  C-4.  Standby  Arrangement 


.Syntax 

Type 

Define  "Y1":  {xl  x2}  x4  x5 

where  x  1  and  x2  compose  the  standby  circuit, 
x4  and  x5  denote  the  switch  and  monitor,  and 
the  CFE  name  is  "Y1 ." 

Each  element  is  displayed  in  one  of  three  colors,  which  specifies  the  element's 
condition.  Elements  that  are  being  used  to  define  a  CFE  ("busy")  are  displayed  in  yellow. 
The  element  with  the  highest  failure  rate  is  displayed  in  red  if  it  is  not  busy.  All  other 
elements  are  displayed  in  black. 


Figure  C-3.  Example  CFE  Containing  a  Standby  Redundancy 


d.  Edit 

The  function  option  "Edit"  allows  the  part  identification  attributes,  block  ID,  part 
ID,  and  part  description,  to  be  edited.  A  pointer  appears  on  the  screen  that  allows  scrolling 
through  these  three  attributes.  When  the  pointer  is  on  a  CFE,  its  definition  is  displayed  at 
the  top  of  the  screen.  Press  <Enter>  at  the  attribute  to  be  edited.  A  window  appears  that 
allows  the  block  ID,  part  ID,  or  description  to  be  changed.  An  element's  block  ID  cannot 
be  edited  if  it  is  included  in  the  definition  of  another  CFE,  nor  can  the  definition  of  a  CFE 
be  changed  if  it  is  being  used  to  define  another  CFE.  To  edit  the  definition  of  a  CFE,  press 
the  space  bar  at  any  of  the  element's  attributes  listed  above. 

e.  View 

The  "View"  option  allows  the  operators  to  scroll  through  all  of  the  attributes  toggled 
on  in  "Select." 

f.  Change 

Press  <Enter>  and  a  pointer  will  appear  on  the  screen  that  can  scroll  through  all  of 
the  attributes  toggled  on  in  "Select"  Position  the  pointer  at  the  desired  attribute  with  arrow 
keys  and  press  <Enter>.  A  window  appears  that  allows  the  value  of  the  attribute  to  be 
changed  (see  Figure  C-4).  Enter  the  new  value  and  press  <Enter>.  Use  the  "Change” 
option  to  change  the  default  values  assigned  to  the  attributes  in  "Add." 
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CHANGE  COMPONENT  DATA 


SysRel  u/R: 0.860534 


Actiue:ARSR4DBM 


Block 

Fart  Description 

Repair 

Total 

Required 

Max-Nun 

ID 

ID 

Tine 

(hrs) 

Units 

Units 

Units 

al  SUFI 

pulse  coap. 

2.0 

1 

1 

1 

a2  SWF2 

doppler  filter 

2.0 

1 

1 

1 

a3  SUP3 

PD  I 

2.0 

1 

1 

1 

a4  SWP4 

CFAR 

2.0 

1 

1 

1 

a5  SUF5 

channel  interface 

2.0 

1 

1 

1 

a6  SUP6 

AMSF  channel 

2.0 

7 

6 

7 

a7  SWF7 

AMSF  interface 

2.0 

4 

3 

4 

a8  SWF8 

beacon  tine  aonit. 

2.0 

2 

1 

2 

aS  SWP9 

beacon  TTG 

2.0 

2 

1 

2 

ale  SWF 10 

beacon  code  extr. 

2.0 

2 

1 

2 

all  BDF1 

video  quantizer 

2.0 

2 

1 

2 

a 12  BDP2 

defruiter 

2.0 

2 

1 

2 

al3‘ BDP3 

bus/tx  beacon 

2.0 

2 

1 

2 

Allouable  range  0.0  to  10000.0  (  2.0]: 
al  Repair  Tine  (hrs)  ==>  2.0 


<ENTER>  Accept  Current  Ualue  <ESC>  Exit 


Figure  C-4.  The  Change  Option 


g.  Remove 


To  remove  a  CFE  or  LFE  from  the  parts  list,  press  <Enter>  and  a  pointer  will 
appear  on  the  screen.  Position  the  pointer  at  the  fur  >al  element  to  be  removed  and 
press  <Enter>.  When  the  pointer  is  on  a  CFE,  its  defin  e  i  is  displayed  at  the  top  of  the 
screen.  An  element  being  used  in  a  CFE  cannot  be  removed  unless  the  CFE  is  removed 
first 

h.  Include 

The  "Include"  option  allows  configurations  with  their  own  parameters  to  be  added 
to  other  configurations  as  elements.  Upon  selecting  this  option,  the  operator  is  placed  in 
the  list  of  existing  files.  The  configuration  to  be  included  is  loaded  from  this  list  The  new 
included  configuration  will  be  treated  as  an  LFE,  requiring  a  block  ID,  part  ID,  and  part 
description.  The  default  part  description  is  the  name  of  the  included  configuration: 
however,  it  may  be  changed.  To  insert  the  configuration  on  the  screen,  position  it  with  the 
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arrow  keys  and  press  <Enter>.  Since  an  included  configuration  is  treated  as  an  LFE,  it  can 
only  be  placed  in  the  LFE  list 


i .  Parameters 

Parameters  are  quantities  that  apply  to  the  whole  configuration.  Default  values  are 
assigned  to  parameters  initially  but  can  be  changed.  Some  parameters  are  dependent,  and 
some  are  calculated  and  cannot  be  changed.  Press  <Enter>  at  the  highlighted  parameter  and 
a  window  will  appear  that  allows  the  parameter  value  to  be  changed.  Parameters  that  can 
be  edited  include  mission  time,  hours  and  days  between  maintenance  visits,  and 
maintenance  visits  per  year.  Changing  the  number  of  maintenance  visits  per  hour,  day,  or 
year  causes  the  other  two  to  be  recalculated  accordingly.  The  MTBCF,  system  reliability 
with  repair,  system  reliability  without  repair,  series  failure  rate,  and  series  mean  time 
between  failures  are  parameters  computed  from  the  other  parameters  and  may  not  be 
changed.  See  Figure  C-5  for  illustration.  The  equations  used  to  compute  these  values  are 
given  in  the  following  sections. 


UlEU/CHAMGE  PARAMETERS  SysRel  u/R:0. 860934  Active:ARSR4DBM 


Block  Part 
ID  ID 


Description 


Total 


a 10  SUP16 
all  BDP1 
alZ  BDPZ 
al3BDP3 
al4  BDP4 
a IS  BDP5 
a 16  BDP6 


Required 
Jnits 


al  SUFI 

Service  Life  (years) 

Mission  Tine  (hours) 
Maintenance  Interval  Levels 

1.0 

500 

3 

aZ  SWPZ 

Maintenance  interval  T1  (hrs) 

100.0 

a3  SUP3 

Maintenance  Interval  TZ  (hrs) 

400.0 

a4  SWP4 

Maintenance  Interval  T3  (hrs) 

800.0 

a5  SWP5 

Systen  Reliability  u/Repair 

0.8609341 

a6  SUF6 

Systen  Reliability  u/o  Repair 

0.84ZZ870 

a?  SWP7 

Series  Failure  Rate  (Fr/lWr) 

1686.36 

a0  SWP8 

MTBCF  (hours) 

3339.7 

a9  SWP9 

HTBF  (series)  (hours) 

593.0 

video  quantizer 
defruiter 
bus/tx  beacon 
bus/tx  tdy 
global  nenory 
global  we  non 


Z.0 

z.e 

Z.0 

Z.0 

z.e 

Z.0 


z 

z 

z 

z 

z 

z 


i 

i 

i 

i 

i 

6 

3 

1 

1 

1 

1 

1 

1 

1 

1 

1 


Max-Nun 

Units 


1 

1 

1 

1 

1 

7 

4 

Z 

Z 

Z 

Z 

Z 

Z 

Z 

Z 

Z 


<EHTER>  Select 


<ESC>  Exit 


Figure  C-5.  The  View/Change  Parameters  Option 


> 


The  system  series  failure  rate  is  calculated  in  failures  per  million  hours  (Fr/Mhr) 

8S  =  81  +  82  + ...  +  8n 

where  8i  is  the  element  failure  rate  times  the  number  of  elements  (i.e.,  series  failure  rate). 
The  system  series  mean  time  between  failure  (MTBF)  is  then  given  by 

106/8S  hr 


The  MTBCF  is  calculated  in  hours  by  the  following  equation 

T 


T(j+i) 


J 


R  (t)  dx 


SI  ■'“-W 


where  Rx(t)  is  the  reliability  function  of  a  system  in  which  maintenance  is  performed  every 
T  hours,  and  t  is  the  mission  time: 

Rt  (t)  =  [Rt  (T)]J  R  (x) 
t=jT  +  x  j  =0,1,2,...;  0  <x  <T 

The  cost  of  a  maintenance  visit  is  calculated  by 

X  (l-Ri(T))  ($/manhour)  ti 
ni 


The  cost  of  spares  is  calculated  by 


X(l-Ri(D)(costi) 

ni 

where  n  is  the  number  of  each  ith  element  in  the  system,  tj  is  the  repair  time  required  for  the 
ith  element,  and  costj  is  the  cost  of  the  ith  element. 

The  LCC  is  calculated  by  adding  the  acquisition  and  support  costs.  The  proxy  used 
for  the  acquisition  cost  is  the  total  system  cost,  which  is  just  the  sum  of  the  parts  costs. 
The  proxy  for  the  support  costs  is  calculated  by  multiplying  the  sum  of  the  maintenance 
visit  cost,  the  spares  cost,  and  the  travel  cost  by  the  number  of  maintenance  visits  per  year. 
This  yearly  maintenance  cost  is  discounted  over  the  total  mission  time  in  years  using  the 
following  equation,  and  the  result  is  then  added  to  the  total  system  cost  to  obtain  the  LCC. 

X  (yearly  maintenance  visit  cost)/(l+discount  rate)i 
i=  1  ->n 
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Sample  Calculations  of  Parameters 


Compare  the  parameter  values  that  follow  with  those  found  in  Figure  C-6.  The 
board  displayed  in  Figure  C-6  is  the  system  described  in  the  following  paragraph. 

Consider  two  identical  components  in  an  active  parallel  configuration  with  an 
element  failure  rate  of  0.01  failures  per  hour,  a  mission  time  of  100  hours,  and  a  time  of 
T  *  50  hours  between  maintenance  visits.  The  reliability  of  the  parallel  system  is 

R(t)  =  1  -  [1  -  e-5*]2  =  2 e-*  -  e'2^  =  2e-«/100  -  e-^O 
The  series  failure  rate  is 

5S  =  5i  +  $2  =  10,000  +  10,000  =  20,000  F/Mhr 
and  the  series  MTBF  =  106/8S  =  106/20,000  =  50  hr 


The  MTBCF  is  calculated  as 


MTBCF(T=50)  = 


1 

J  R(x)dx 

o _ 

1  -  R(T) 


T 


f  [2e''t/100  -  e-«°]  dx 

0 _ 

1  -  (2e'T/10°  -  e'T/5°) 


_  150  +  50e  T/so  -  200e  T/10° 
l-2e-T/100  +  e-T/5° 

and  the  system  reliability  with  repair  is 


=  304.1  hours 


Rl<t)  =  [Rt(T)P  R(t) 


=  [2e-T/l00 .  e_T/50p  [2e-t/l00 .  e-x/50j 
=  [26-50/100  -  e-50/50]2  [2e-0/100 .  e-0/50] 
=  0.7143324 


The  equation  describing  the  reliability  with  repair  versus  mission  time  curve  for  T  =  50 
hours  is 


RtO)  =  [2e-5  -  e-lp  Pe-'tflOO  -  e-^O] 
where  j  is  the  maintenance  visit  counter,  j  =  1,2,3, ...;  0  <  x  <50  hours. 
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j.  Graph 

Two  graphs  can  be  displayed.  The  "Mission"  option  plots  the  reliability  versus 
mission  time  and  the  "Visits"  option  plots  the  MTBCF  versus  the  maintenance  visits  per 
year.  The  space  bar  is  used  to  toggle  between  the  model  curves-the  series  configuration 
(red),  the  configuration  with  redundancies  (green),  and  the  configuration  with  redundancies 
and  repair  (blue).  The  model  curve  is  generated  from  the  equation  for  system  reliability, 
and  the  series  curve  from  the  series  failure  rate.  To  move  along  the  curve,  the  arrow  keys 
are  used.  Press  <Esc>  to  exit  the  graphs.  See  Figures  C-6  and  C-7. 


i 


Mission  tins  vs.  Reliability 


Figure  C-6.  Reliability  Versus  Mission  Time 
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k.  File 

The  "File"  selection  option  allows  loading  of  existing  files,  creating  new  files, 
removing  files,  and  storing  of  files  under  "Save"  or  "Save  As."  To  load  an  existing  file, 
enter  the  "Load"  option  within  "File"  and  a  new  screen  will  appear  displaying  the  names  of 
existing  files.  Use  the  arrow  keys  to  select  a  file  and  press  <Enter>  to  retrieve  it.  The 
active  system  remains  active  until  another  system  is  loaded  by  the  "Load"  option.  Multiple 
copies  of  one  set  of  system  data  or  reports  with  different  fields  selected  are  therefore 
possible.  To  create  a  new  file,  enter  the  "New"  option  and  a  window  will  appear.  Type 
the  name  of  the  new  file  (maximum  of  eight  letters)  and  press  <Enter>.  Files  may  be 
stored  using  "Save"  or  stored  under  another  name  using  "Save  As."  If  a  file  is  saved  under 
another  name,  the  file  under  the  old  name  is  stored  and  the  file  under  its  new  name  is  made 
active.  Before  the  program  exits,  the  program  asks  whether  the  changes  (if  any)  to  the 
active  file  should  be  saved. 
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C.  BLOCK  DIAGRAM  NODE 


In  "Block  Diagram,”  the  elements  in  the  configuration  graphics  are  identified  by 
their  pan  IDs.  The  shaded  boxes  designate  CFEs.  The  LFEs  contained  in  the  shaded 
boxes  illustrate  the  configuration  of  the  CFE,  and  the  CFEs  pan  ID  is  displayed  in  the 
lower  left  comer  of  the  box.  The  different  types  of  redundancies  are  indicated  on  the  block 
diagram  by  the  location  of  the  ratio  of  the  required  to  total  number  of  elements.  The  block 
diagram  for  the  configuration  built  in  Section  B.2  is  shown  in  Figure  C-8.  If  the  redundant 
elements  are  different,  such  as  seen  in  CFE  "c2,"  the  ratio  of  required  to  total  number  of 
elements  will  be  displayed  in  the  upper  left  hand  comer  of  the  boxed  CFE.  If  the  redundant 
elements  are  identical,  such  as  CFE  "bl"  and  "cl,"  the  ratio  will  be  shown  in  the  shaded 
boxed  region  above  the  CFE.  CFEs  are  defined  in  the  program  using  the  LFEs’  block  IDs. 
In  this  example,  the  part  IDs  were  given  the  same  names  as  the  corresponding  block  IDs  to 
show  component  placement 

The  redundancy  of  CFE  "cl"  is  analogous  to  that  of  CFE  "bl,"  except  that  the 
entire  configuration  composes  one  path.  Thus,  three  of  the  configurations  shown  are  in 
parallel,  with  two  required  for  system  success. 


Figure  C-8.  Reliability  Block  Diagram 
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D.  REPORTS  NODE 

The  report  generator  ("Reports"  on  the  reliability  tree)  is  used  to  print  out  reports  of 
the  reliability  data  for  a  given  configuration.  Reports  for  more  than  one  configuration  can 
be  printed  in  one  session.  When  called  from  the  tree,  the  report  generator  automatically 
loads  the  last  system  worked  on.  If  another  system  is  desired  or  data  for  more  than  one 
system  is  to  be  printed  in  the  same  session,  use  th»~  'Load"  option  (a  description  follows). 

The  report  consists  of  a  cover  page  and  a  table  of  data.  The  cover  page  includes  a 
title,  date,  configuration  name,  and  the  configuration  parameters.  The  table  consists  of  the 
Block  ID,  Part  ED,  Description,  and  the  fields  selected  in  the  Select  option.  The  table 
(every  page  of  the  table,  if  more  than  one  page  long)  is  headed  by  a  title,  date, 
configuration  name,  and  the  names  of  the  selected  fields. 

The  following  paragraphs  descnbe  the  four  options  in  the  main  menu  of  the  report 
generator. 

1 .  Load 

The  "Load"  option  is  used  to  select  an  active  configuration  for  a  report.  Upon 
entering  the  "Load"  option,  a  list  of  available  configurations  is  given.  To  select  one,  move 
the  highlight  bar  to  the  configuration  desired  and  press  <Enter>.  The  configuration  data  are 
loaded,  and  the  main  menu  is  redisplayed  with  the  new  active  configuration  name  displayed 
in  the  upper  right  comer  of  the  screen.  To  return  to  the  main  menu  without  loading  a  new 
configuration,  press  <Esc>. 

2 .  Select 

The  "Select"  option  is  used  to  specify  the  data  fields  that  are  to  be  included  in  the 
report  for  the  active  configuration.  A  minimum  of  four  and  a  maximum  of  ten  fields  may 
be  chosen.  Choose  a  field  by  placing  the  highlight  bar  on  the  desired  field  and  pressing 
<Enter>.  The  fields  toggle  between  on  and  off,  red  indicating  on  and  black  indicating  off. 
Press  <Esc>  when  finished  to  return  to  the  main  menu. 

3.  Print 

The  "Print"  option  begins  printing  of  the  report.  The  prompt  "Are  you  using  a  laser 
printer?"  appears.  The  printer  should  be  connected,  turned  on,  set  on-line,  aud  positioned 
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at  the  top  of  the  paper  before  answering  this  prompt  The  printer  can  be  set  up  anytime 
earlier,  but  must  be  done,  at  the  latest,  at  this  prompt 

4 .  Exit 

The  "exit"  option  exits  the  report  generator  and  returns  to  the  tree. 

E.  MAINTAINABILITY  MODELING 

The  Maintainability  Modeling  Module  is  accessed  through  the  CALCE  Printed 
Wiring  Board  (PWB)  Design  Environment  tree  shown  in  Figure  C-9.  When  this  node  is 
selected,  the  user  may  view  all  of  the  elements  that  make  up  the  system  or  subsystem 
currently  being  analyzed  (Figure  C-10).  The  View  Components  option  allows  scrolling 
through  all  of  the  elements  in  the  list.  When  an  element  is  selected  for  a  failure  mode 
analysis,  the  Failure  Mode  menu  automatically  appears  (Figure  C-ll). 


PUB  DESIGH  ENUIRONHENT  JJERSIOH  2.0 
-"Congestion 


— Placement 


Active:  MIKE 


-Restore  Layout 
-jteliabi  1  ity 
-  Force  Directed 


— ;-Therea  1  Analysis  Funct i ons 


f  Power  Display 
Theraa 1  Ana lys is 


*—  Rad iat i on  Effects 


—  Reliability  Functions 


—  Reliability  Modeling 

—  Maintainability  Mode 

Display  Model 

Set  Environment 

—  RADC  Derating 

Notes 

1 

*—  Redundancy  Allocation 

p-  PTH  Reliability 

Figure  C-9.  The  CALCE  PWB  Design  Environment  Tree 
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Uieu  Components  Failure  Modes  Elemental  Tasks  Analysis  Xit 


Node 

ID 

Coop . 
ID 

Component 

Description 

MTTB 

(hrs. ) 

Failure  Rate 
(fail./E6  hr.) 

Failure 
Analysis  ? 

ARSR-1A 

01 

PULSE  COMP 

0.90 

11.77 

ARSR-1A 

02 

DOPPLER  FILTER 

8.12 

17.23 

YES 

ARSR-1A 

03 

PDI 

1.80 

11.19 

YES 

ABSR-1A 

01 

CFAR 

2.63 

13.31 

YES 

ARSR-1A 

05 

CHANNEL  INTERFACE 

3.20 

6.56 

YES 

Uieu  Component  List 

Figure  C-10.  The  View  Components  Screen 
flaintainability  Prediction  Active  AftSIMA  ICTR  3.13 


Uieu  Components 

Failure  Nodes  Elei 

■ental  Tasks  Analysis  Xit 

1 

Uieu  Failure  Nodes 
Edit  Failure  Nodes 
Repair  Nethod 

DOPPLER  FILTER 

PDI 

CFAR 

CHANNEL  INTERFACE 

NTTR  Failure  Rate  Failure 
(hrs.)  (fai 1 ./E6  hr. )  Analysis  ? 

ARSR-1A  01  | 

ARSR-1A  02 

ARSR-1A  03 

ARSR-1A  01 

ARSR-1A  05 

0.00  11.77  YES 

8.12  17.23  YES 

1.80  11.19  YES 

2.63  13.31  YES 

3.20  6.56  YES 

Uieu  Pa i lure  nodes 

Figure  C-11.  The  Failure  Modes  Menu 
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1.  Failure  Modes 


When  a  Failure  Modes  option  is  selected  for  a  component,  the  screen  of  failure 
modes  appears  (Figure  C-12).  From  the  Failure  Modes  menu,  the  user  can  edit  the  failure 
mode  list  for  the  selected  component  (Figure  C-13).  When  a  failure  mode  is  selected,  the 
Repair  Method  screen  appears  (Figure  C-14). 


Maintainability  Prediction  Active  ARSR-4A  HTTR  3.13 

Uieu  Components  failure  Modes  Eleeental  Tasks  Analysis  Xit 


Edit/Uieu  Failure  Modes 

Figure  C-12.  The  Failure  Modes  Screen 
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Maintainability  Prediction  Active  AISR-4A 

Uieu  Coaponen ts  Failure  Modes  Eleaental  Tasks 


mn  3.43 

Analysis  Xit 


Failure  II 
Description 

Uiew  Failure  Modes 
Edit  Failure  Modes 

FDII 

Isolation 

■ 

Percent 

Frequency 

Repair 

Tiae 

Failure  Mode  1  jj 

Add  Failure  Mode 

l  79 

8 

5.80 

Failure  Mode  2 

Delete  Failure  Mode 

39 

a 

8.58 

Type  1  False  Alar*: 

Change  Failure  Mode 

eolation 

8 

NO 

Tune  2  False  Alara: 

J  to  LRU 

8 

NO 

Add  a  Failure  Mode 

Figure  C-13. 

The  Edit  Failure  Modes 

Menu 

Maintainability  Prediction 

Active  ARSR-4A 

HTTR  3.43 

Uieu  Coaponents  Failure  Modes  Eleaental  Tasks 

Analysis  Xit 

Repair  Task 

Description 

Task  Tiae 
(E-5  hours) 

Repetitions 

Notify  Manageaent 

58866 

1 

Travel  to  Site 

56666 

4 

Travel  to  Site 

56666 

1 

DIFFICULT 

1818 

2 

1-1/4  TO  1  INCH,  MODERATE 

856 

18 

CURRENT  MEASUREMENT,  DECADE  BOX 

4448 

18 

CASE  1 

2868 

58 

Systea  Checkout 

58866 

1 

Edit/Uieu  Failure  Modes 


Figure  C-14.  The  Repair  Methods  Screen 
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2.  Repair  Methods 

From  the  Repair  Methods  menu  (Figure  C-15),  a  component  analysis  can  be 
performed  that  verifies  that  the  entered  data  are  valid  (i.e.,  ensures  that  the  sum  of  the 
percentages  is  100  and  that  repair  methods  exist  for  each  failure  mode),  calculates  the  mean 
repair  time,  and  updates  the  main  reliability  data  base  with  the  results.  This  menu  is  used  to 
enter  all  of  the  maintenance  steps  required  to  return  the  system  to  operation  after  the 
specified  failure  has  occurred.  At  least  one  elemental  task  should  be  entered  for  each  of  the 
eight  major  tasks  (preparation,  fault  isolation,  disassembly,  interchange,  reassembly, 
alignment,  checkout,  and  start-up)  outlined  in  Military  Handbook  472,  Procedure  5.  When 
the  correct  task  has  been  selected,  the  user  is  prompted  for  the  manpower  requirements  and 
the  number  of  repetitions  necessary  to  perform  the  task  for  the  current  repair.  If  a  task 
requires  only  one  person  but  two  people  are  required  for  the  preceding  and  following  tasks 
(making  it  possible  for  the  second  person  to  do  something  else  useful  during  the 
performance  of  the  first  task),  the  manpower  requirement  for  this  task  should  be  listed  as 
two.  Repair  tasks  can  be  deleted,  modified,  and  viewed  in  the  same  way  as  failure  modes. 
The  repair  tasks  arc  selected  from  the  file  of  Elemental  Maintenance  Tasks  (Figure  C-16). 


Maintainability  Prediction  Active  ARSR-4A 

Uicu  Components  Failure  nodes  Elemental  Tasks 


Repair  Task 
Description! 


:nt 


Notify  Manage* 
Travel  to  Site 
Travel  to  Site 
DIFFICULT 
1-1/4  TO  1  INCH,  MOO! 
CURRENT  MEASUREMENT , 
CASE  1 

System  Checkout 


MTTR  3.43 
Analysis  Xit 


Uieu  Failure  Modes 
Edit  Failure  Nodes 
Repair  Method 


Uieu  Repair  Tasks 
Edit  Repair  Tasks 


Add  Repair  Task 
Delete  Repair  Task 
Change  Repair  Task 


Task  Time 
(E-5  hours) 


Repetitions 


r/\AAA 

Jvwv 

seeee 

56000 

1810 

850 

4440 

2860 

50800 


1. 

4 

1 

2 

16 

10 

50 

1 


Add  an  Elemental  Task  to  Repair  Method 


Figure  C-15.  The  Repair  Method  Menu 
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Maintainability  Prediction  Active  ARSR-4A  HTTR  3.43 

Uieu  Components  Failure  Modes  Elemental  Tasks  Analysis  Xit 


Task 

ID  Nueber 

Task 

Description 

Task  Tiee 
(E-5  hours) 

ECA-CM-Dx 

ADJUST  DEUICE 

ECA-CM-D1 

CASE  1 

1Z66 

ECA-CM-Zx 

ADJUST  DEUICE 

ECA-CM-Z1 

CASE  1 

678 

ECA-TA-Dx 

CALIBRATE  COAXIAL  CABLE  TESTER 

ECA-TA-D1 

USED  WITH  58-OHM  CABLE 

7950 

ECA-TA-DZ 

USED  WITH  OTHER  THAN  58-OHM  CABLE 

4790 

ECL-FX-Dx 

CLEANING  FLUX.  UP  TO  3-INCH  STROKE 

ECL-FX-D1 

CASE  1 

ZZ9 

ECL-FX-Zx 

CLEANING  FLUX,  UP  TO  3- INCH  STROKE 

ECL-FX-Z1 

CASE  1 

84 

ECL-HC-Rx 

CONFORMAL  COATING,  EPOXY,  AND  URETHANES 

ECL-HC-R1 

CASE  1 

471 

ECL-HC-Yx 

CONFORMAL  COATING,  EPOXY,  AND  URETHANES 

ECL-HC-Y1 

CASE  1 

308 

ECL-SE-Dx 

CLEAN  SOLDERING  IRON 

ECL-SE-D1 

CASE  1 

38 

Edit/Uieu  Lists  of  Elemental  Maintenance  Tasks 


Figure  C-16.  The  Elemental  Maintenance  Tasks  Screen 
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3.  Elemental  Tasks 

The  Elemental  Tasks  menu  is  used  to  edit  the  generic  lists  of  elemental  maintenance 
ra sics  (Figure  C-17).  From  this  menu  the  user  adds,  deletes,  modifies,  and  views  the  tasks 
in  the  currently  active  file.  The  user  may  also  activate  different  elemental  task  files  or  create 
new  files. 


Maintainability  Prediction  Active  ARSR-4A 

Uieu  Components  Failure  Modes  Elemental  Tasks 


HTTR  3.43 
Analysis  Xit 


Task 
ID  Number 


Task 
Description 


Uieu  Eleaental  Tasks 
Edit  Eleaental  Tasks 


Task  Tiae 
(E-5  hours) 


Add  Eleaental  Task 
Delete  Elemental  Task 
Change  Eleaental  Task 


ECA-CM-Dx  ADJUST  DEUICE 

ECA-CM-D1  CASE  1 

ECA-CH-Zx  ADJUST  DEUICE 

ECA-CM-Z1  CASE  1 

ECA-TA-Dx  CALIBRATE  COAXIAL  CABLE  TESTER 

ECA-TA-D1  USED  WITH  50-OHM  CABLE 

ECA-TA-DZ  USED  WITH  OTHER  THAN  50-OHM  CABLE 

ECL-FX-Dx  CLEANING  FLUX,  UP  TO  3- INCH  STROKE 

ECL-FX-D1  CASE  1 

ECL-FX-Zx  CLEANING  FLUX,  UP  TO  3- INCH  STROKE 
ECL-FX-Z1  CASE  1 

ECL-HC-Rx  CONFORMAL  COATING,  EPOXY,  AND  URETHANES 
ECL-HC-R1  CASE  1 

ECL-HC-Yx  CONFORMAL  COATING.  EPOXY,  AND  URETHANES 
ECL-HC-Y1  CASE  1 

ECL-SE-Dx  CLEAN  SOLDERING  IRON 

ECL-SE-D1  CASE  1 


1200 

870 

7950 

4790 

2Z9 

84 

471 

368 

38 


Add  an  Eleaental  Maintenance  Task 


Figure  C-17.  The  Edit  Elemental  Maintenance  Tasks  Menu 
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4.  Analysis 

At  any  time,  a  system  or  component  maintainability  analysis  can  be  done  using  the 
Analysis  option  (Figure  C-18).  The  system  analysis  for  the  ARSR-4A  is  shown  on  the 
screen  in  Figure  C-19. 


Ha inta inability  Prediction  Active  ARSR-4A  HTTR  3.43 

Uicw  Components  Failure  Modes  Eleaental  Tasks  Analysis  Xit 


Task 

Task  1 

Systea  Analysis 

| 

ID  Nuaber 

Description 

Coaponent  Analysis 

ECA-CM-Dx 

ADJUST  DEUICE 

JBSSSBSB 

r 

ECA-CM-D1 

CASE  1 

1200 

ECA-CH-Zx 

ADJUST  DEUICE 

ECA-CM-Z1 

CASE  1 

670 

ECA-TA-Dx 

CALIBRATE  COAXIAL  CABLE  TESTER 

ECA-TA-D1 

USED  WITH  59-OHH  CABLE 

7950 

ECA-TA-D2 

USED  WITH  OTHER  THAN  50-OHM  CABLE 

4790 

ECL-FX-Dx 

CLEANING  FLUX.  UP  TO  3- INCH  STROKE 

ECL-FX-D1 

CASE  1 

229 

ECL-FX-Zx 

CLEANING  FLUX,  UP  TO  3- INCH  STROKE 

ECL-FX-Z1 

CASE  1 

84 

ECL-HC-Rx 

CONFORMAL  COATING,  EPOXY,  AND  URETHANES 

ECL-HC-R1 

CASE  1 

471 

ECL-HC-Yx 

CONFORMAL  COATING.  EPOXY,  AND  URETHANES 

ECL-HC-Y1 

CASE  1 

308 

ECL-SE-Dx 

CLEAN  SOLDERING  IRON 

ECL-SE-D1 

CASE  1 

38 

Calculate  Systea  Maintainability 


Figure  C-18.  The  Analysis  Option 
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Analyze  Systea  Maintainability 


Active  ARSR-4A 


Task  _ Task  Task  Tiae 


Nuaber  hours) 


-  ARSR-4A  - 

ECA-CH-Dx  — - 

ECA-CH-D1  HTTR  3.430093E*0000  1200 

ECA-CM-Zx  MMH/Repair  3.430093E+0000 

ECA-Cn-Zl  NMH/HA  3.430093E+0000  670 

ECA-TA-Dx  MMH/OH  2.267017E-0004 

ECA-TA-D1  7950 

ECA-TA-D2  4790 

ECL-FX-Dx 

ECL-FX-D1  229 

ECL-FX-Zx  _ 

ecl-fx-zi 

ECL-HC-Rx  CONFORMAL  COATING,  EPOXY,  AND  URETHANES 

ECL-HC-R1  CASE  1  471 

ECL-HC-Yx  CONFORMAL  COATING,  EPOXY,  AND  URETHANES 

ECL-HC-Y1  CASE  1  308 

ECL-SE-Dx  CLEAN  SOLDERING  IRON 

ECL-SE-D1  CASE  1  38 


<Esc>  Menu 

Figure  C-19.  A  System  Maintainability  Analysis 
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